flutter_html_vuetify 0.2.0 copy "flutter_html_vuetify: ^0.2.0" to clipboard
flutter_html_vuetify: ^0.2.0 copied to clipboard

Published 2 days ago • verified publisherchaosworld.cc
SDKFlutter
PlatformAndroidiOSLinuxmacOSwebWindows
→

Metadata

A flutter_html extension that inlines Vuetify utility classes as CSS.

More...

0.2.0 #

  • Renamed from flutter_html_vuetify_extension on pub.flutter-io.cn. The old package stays published and is marked discontinued with this one as its replacement. Class names are unchanged.

0.1.2 #

  • One more companion extension is recognised: flutter_html_css_text_metrics (CssTextMetricsHtmlExtension), for letter-spacing, word-spacing and text-decoration-thickness. Eight companions in total.
  • What comes alive: the letter-spacing on twelve of the thirteen text-* typography classes. text-h5 is the one that states none. Registered alongside flutter_html_css_font_size, the whole typography scale now renders as written, and text-h4 and its siblings leave the report entirely instead of being named for a declaration nothing could restore.
  • A data addition to knownCompanionExtensions, with no new dependency: detection is by class name, as before. The property set is copied verbatim from that package's kCssTextMetricsProperties, so word-spacing and text-decoration-thickness are listed although no Vuetify class emits either. font-family is absent there and here: flutter_html parses it already.
  • isSupportedClass and unsupportedClasses are unchanged. Both answer for bare flutter_html, and 618 classes still render nothing without a companion.

0.1.1 #

  • New diagnostic, for a different failure than the class one: an element whose Vuetify classes this package resolved, on a tag flutter_html 3.0.0 cannot render, is now named once per parsed document. Same channel as UnsupportedVuetifyClassesException: handed to FlutterError.reportError, never thrown. Gate it with reportUnrenderableTags: false.
  • This one bites Vuetify markup hardest, because <v-card> and friends are exactly the tags nothing claims. prepareFromExtension hands back an EmptyContentElement and the element and its whole subtree render nothing, silently. Inlining pa-4 onto it was always pointless.
  • supportedTags still lists v-card, v-btn, v-icon, v-col, v-row and v-container, and its dartdoc now says what that set is: a declaration of intent, not a filter. flutter_html reads supportedTags only in the default HtmlExtension.matches, which this class overrides. There is a test that pins it: the set lists v-card, and <v-card> still renders nothing. example/example.md used to document the set as a feature.
  • reportUnrenderableTags is deliberately not folded into reportUnsupportedClasses. The class report fires on ordinary Vuetify markup, so people turn it off; the tag report only fires when something disappeared. One flag would let the loud one silence the quiet one.
  • The report goes quiet once you register the TagExtension it asked for. It re-runs prepareFromExtension's own check against the registered extensions instead of trusting a static list.
  • This needs flutter_html_class_to_css 0.1.1, where kFlutterHtmlRenderableTags and the reporter live so the two utility packages do not each carry a copy of the 70-tag set. Release order is converter 0.1.1, then flutter_html_bootstrap 0.1.2, then this. UnrenderableTagsException and kFlutterHtmlRenderableTags are re-exported here, so reading a report needs no direct dependency on the converter.
  • Docs pass to the family style. The category table, the companion table and the size-constraints note moved to doc/unsupported-classes.md, linked by absolute URL so it works from pub.flutter-io.cn; the README gained the tag trap. New .pubignore is a verbatim copy of .gitignore plus doc/, because .pubignore replaces .gitignore rather than extending it.
  • border-opacity-* resolving to nothing is by design, not a gap. Upstream the class compiles to --v-border-opacity alone, a custom property only the border* classes read back through border-color, so on its own it renders nothing in Vuetify either. The invariants test pins the six classes exactly.
  • Four more companion extensions are recognised in knownCompanionExtensions:
    • CssEffectsHtmlExtension from flutter_html_css_effects, for opacity, box-shadow and visibility.
    • CssSizeConstraintsHtmlExtension from flutter_html_css_size_constraints, for max-width, min-width, max-height and min-height.
    • CssInteractionHtmlExtension from flutter_html_css_interaction, for cursor, pointer-events and user-select.
    • CssTextOverflowHtmlExtension from flutter_html_css_text_overflow, for text-overflow, white-space and -webkit-line-clamp.
  • Registering one of them stops this package from suppressing the CSS that companion renders, and stops it from reporting the classes that resolve to it. In practice that brings back elevation-0..elevation-24 and opacity-0..opacity-100 with the effects extension, every cursor-* class with the interaction extension, and text-truncate, text-no-wrap and text-pre-wrap with the text-overflow extension. No class in this package resolves to a size constraint, so that entry unlocks nothing today.
  • This only takes effect if the companion package is a dependency and listed in the same Html(extensions: [...]), after VuetifyHtmlExtension(). Naming it in pubspec.yaml alone changes nothing.
  • Detection is by class name, so a companion that renames its extension class goes undetected and its properties are dropped and reported again.
  • Docs correction. The README explained the border-radius companion's ordering requirement with the wrong reason. There are two independent requirements. Its wrapIfHasAnyClass must stay at the default true, because flutter_html prepares the element tree before this extension expands a class into style="", so the companion never sees rounded-* at prepare time in any order. Listing it after this extension is separate, and is what lets it extract border and margin. Listed first it still clips, but a border on a rounded element renders square around the clip.
  • VuetifyCompanionExtension gained an optional summary, describing in prose which Vuetify classes each companion brings back. It is documentation for anyone reading knownCompanionExtensions; nothing parses it and it does not appear in the report.
  • CssFlexHtmlExtension from flutter_html_css_flex is recognised as well, and it is the one companion that needed more than a table entry. display is dropped by value: flutter_html parses the property and reads every keyword outside its five as Display.inline, so a widened property set gets a display declaration as far as the value check and no further. An entry now carries a displayValues set beside its properties set, and that value set travels with the property set through _isRenderable and into the report.
  • What it brings back: d-flex, d-inline-flex, every flex-*, justify-*, align-*, align-content-* and order-* class, and ga-*. The d-*-table* classes stay dropped, because nothing renders display: table, and they are still named in the report.
  • Nothing changes for an app that does not register it. display: flex is dropped exactly as in 0.1.0, and for the same reason.
  • UnsupportedVuetifyClassesException gained droppedDisplayValues and unrenderableDisplayValues, and companionRemedies credits a companion for display on the value that was dropped rather than on the property. Without that, a document whose only offender was d-sm-table would have been told to register the flex extension, which renders no table. The report text names the companion for the values it does render and says plainly which values nothing renders.
  • Two dartdoc comments were wrong and are fixed. The one on VuetifyCompanionExtension said a flex companion could not work because _isRenderable returns from its display branch before reading the widened property set. It does not: it reads the property set first and then judges the value, which is a different mechanism with the same outcome. The one on knownCompanionExtensions said adding such a companion needs a code change; the code change is now in place, so a second one is a data addition.
  • CssFontSizeHtmlExtension from flutter_html_css_font_size is recognised, and it needed the same kind of code change for the same kind of reason. font-size is a property flutter_html parses and then drops by value: ExpressionMapping.expressionToFontSize has its rem branch commented out. Every class of the text-h1 to text-overline scale states its size in rem, so none of them has ever rendered at the size it names, and the model said nothing because it read properties and not values.
  • An entry now carries a fontSizeUnits set beside its displayValues set, and that third set travels with the other two. _isRenderable, _yieldsRenderableCss and _supportedCssFor pass one _SupportedCss record instead of two loose sets, so a widened property set can no longer be handed round without its value sets. Listing font-size in a companion's properties alone still changes nothing, by design, and there is a test for that trap.
  • flutterHtmlUnrenderableFontSizeUnits is stated as what does not render, the opposite way round from flutterHtmlSupportedDisplayValues. The asymmetry is measured. An unknown display keyword becomes Display.inline, so only an allowlist is safe there. An unknown length unit reaches expressionToFontSize's LengthTerm branch, which reads the number and ignores the unit, so font-size: 12pt renders at 12. The three tokens that render nothing are rem, smaller and larger.
  • isSupportedClass and unsupportedClasses do not move. text-h4 still renders its font-weight and its line-height, and "at least one declaration renders" is still the rule, so the set stays at 618. A class that renders part of what it says needs the report, not that set, and the dartdoc on both now says so.
  • So the report learned to name a partial. UnsupportedVuetifyClassesException gained partialClasses and partiallyDroppedProperties, companionRemedies and unrenderableProperties read the whole-and-partial union, and the text carries a second paragraph for them. Before this, a class that rendered anything at all left the report entirely, which is how a page of headings came to render at body size with nothing said about it anywhere.
  • That makes the report louder than 0.1.0. Every text-* typography class loses its letter-spacing under bare flutter_html, so a document full of typography now reports where it did not. text-truncate with the text-overflow companion registered is the other new case: it renders the ellipsis and the nowrap and still loses its overflow: hidden. reportUnsupportedClasses: false silences the lot, as before.
  • Registering the font-size companion stops the rem being dropped, so the declaration reaches style="" for that extension to resolve at the preProcessing step. Order does not matter there: it reads the inline style after this extension has written it. letter-spacing still has no renderer and stays in the report.
  • Nothing changes for an app that does not register it, except the report. The same rem value was dropped in 0.1.0, by flutter_html rather than here.

0.1.0 #

  • Initial release: a flutter_html extension that inlines Vuetify utility classes (borders, rounded corners, cursor, display, spacing, elevation, and typography) as CSS understood by flutter_html.
  • Declarations flutter_html cannot render are suppressed rather than inlined. This matters beyond tidiness: d-flex resolves to display: flex, which flutter_html maps to Display.inline, turning block elements inline.
  • Unsupported classes are reported once per parsed document via FlutterError.reportError. They are never thrown, so they reach the debug console and crash reporters such as Sentry without interrupting rendering. Gate with reportUnsupportedClasses.
  • A registered companion extension (currently only CssBorderRadiusHtmlExtension) widens what counts as supported, so its properties are inlined instead of dropped.
  • Public API for introspecting coverage: isSupportedClass(), unsupportedClasses, flutterHtmlSupportedProperties, flutterHtmlSupportedDisplayValues, knownCompanionExtensions, VuetifyCompanionExtension and UnsupportedVuetifyClassesException.

← Metadata

0
likes
160
points
52
downloads

Documentation

API reference

Publisher

verified publisherchaosworld.cc

Weekly Downloads

Metadata

A flutter_html extension that inlines Vuetify utility classes as CSS.

Repository (GitLab)
View/report issues
Contributing

Topics

#flutter-html #css #html #extension #vuetify

License

MPL-2.0 (license)

Dependencies

flutter, flutter_html, flutter_html_class_to_css, html

More

Packages that depend on flutter_html_vuetify

Back