StyleAttribute

From HTML WG Wiki
Jump to: navigation, search

HTML5 Issue: Element Styling

Requirement

A way of applying style to individual elements in a document in cases where the style is not known at the time of the global site design.

Status: Unresolved

Use cases

WYSIWYG editors

WYSIWYG editors need to save the styles the user decided to choose, without any information about the intentions for such styling. (#discuss-wysiwyg Discussion)

Non-WYSIWYG editors

Non-WYSIWYG editors (forums, blogs and wikis) offer only a limited set of HTML features to users. But often users want to use arbitrary styles, that can't be predefined by application. (#discuss-non-wysiwyg Discussion)

Computer-generated HTML versions of other document formats

Programs that convert documents in other formats to HTML often don't have the semantical information about the meaning of styles in the convertable document. (#discuss-html-versions Discussion)

Styling of external material (e.g. advertisements)

External content providers need to ensure, that the styles will remain the same in the context of any other page. (#discuss-external-material Discussion)

Very specific small adjustments to a page

If you only want to adjust one single place in one single page, adding style element and new class or id is too complicated. (#discuss-small-adjustments Discussion)

Serialization of DOM

When serializing DOM the dynamically set styles need also to be serialized. (#discuss-dom-serialization Discussion)

HTML embedded to other applications

Transmission of fragments of HTML with their styles preserved. (#discuss-embedding Discussion)

Debugging

There is a need for a standards-based way of settings styles for individual elements. (#discuss-debugging Discussion)

Graphs and diagrams

In dynamically created graphs and diagrams many elements need really varying styling. (#discuss-graphs Discussion)

Possible Solutions

Note that according to current draft, and <style scoped> are to be used together.</i>

The style attribute

Pros:

Cons:

Debatable:

Style attribute with extended syntax

Pros:

Cons:

  • May encourage authors to use inline style where not appropriate

with WYSIWYG signature

Pros:

Cons:

Does not resolve: #external-material External material, #small-adjustments Small adjustments, #dom-serialization Serialization of DOM, #embedding embedded HTML, #debugging Debugging, #graphs Graphs and diagrams. <i>(Assuming, that WYSIWYG signature applies to wider range of applications, not just WYSIWYG editors.)</i>

<style scoped>

Pros:

  • Allows per-media styles

Cons:

Does not resolve: #dom-serialization Serialization of DOM, #debugging Debugging.

<localstyle> element

Pros:

Cons:

  • Verbose in simple (one element) case
  • Does not allow styling of void elements
  • Stylesheet content has to be hidden to existing UAs using comment marks and/or CDATA marks (when in XML serialization)

Does not resolve: #dom-serialization Serialization of DOM, #debugging Debugging.

<style> in <head> + selectors

Pros:

  • Works in existing UAs
  • Allows per-media styles

Cons:

  • Requires access to the <head>
  • Verbose in single element case

Does not resolve: #external-material External material, #dom-serialization Serialization of DOM, #embedding Embedding, #debugging Debugging.

Individual presentation-oriented attributes

Pros:

  • Works in existing UAs
  • Possible to limit attributes to those which make sense in the context of a specific element

Cons:

  • No way to reuse information across multiple elements
  • Requires tight coupling of style and HTML; no possibility to use extra CSS properties as they are introduced without updating HTML
  • Many attributes needed on a single element; reduces source readability
  • No way of providing media-specific style

Discussion

WYSIWYG editors

Current draft allows the use of style attribute in font element for WYSIWYG editors. The document has to include the WYSIWYG signature. HTML 5 Working Draft, 9.1. Presentational markup, 28 June 2007.

There have been multiple concerns about the choice of font element for that purpose. See: #discuss-why-font Why bring back the font element?

Non-WYSIWYG editors

Non-WYSIWYG editors, such as forums, blogs and wikis which use BBCodes or a limited subset of HTML. If the user, for whatever reason, wants to make a paragraph coloured #382f5c, the only current way to do so is a style attribute. Dannii Willis, Wed, 27 Jun 2007

Computer-generated HTML versions of other document formats

The best example is Google giving you the HTML version of .doc or .pdf document. Rene Saarsoo, Sat, 30 Jun 2007.

Styling of external material (e.g. advertisements)

Take advertising agencies that deliver ad code to commercial websites.

Considering a really simple banner ad where the ad company only wants to make sure there appears no border around the banner, there are basically three options:

  1. Hope for each partner to remove an eventual border. (Doesn't work.)
  2. Delivering the ad with 'border="0"' (or worse). (Presentational.)
  3. Delivering the ad with 'style="border: 0;"'. (More kids in town.)

Jens Meiert, Tue, 26 Jun 2007.

Very specific small adjustments to a page

I worked regularly on a site whose authors used regularly to use

in order to adjust letter spacing and font sizing so that headlines of news stories would always take up equal horizontal room. Bruce Lawson, Mon, 25 Jun 2007. I know of several sites that used a CMS in which the editor could specify a specific background image for a news item. This required setting background-image in the style attribute when listing the items (the base formatting was of course handled in a separate CSS file). The programming paradigm of many CMS templating systems relies on UI fragments. Often, these fragments are "self contained" in such that a controller decides what happens in each fragment. Outputting a style definition in the html head is often more complicated than using the inline style attribute to provide "custom" style changes. Peter Krantz, Sun, 1 Jul 2007.

Serialization of DOM

The changes to the .style property are reflected in the style attribute in the DOM, and without the attribute, there would be no conforming way to serialize the DOM after modifying the .style property. Lachlan Hunt, Sat, 30 Jun 2007.

HTML embedded to other applications

One use case for style attributes is syndication. Here's an example. Sam Ruby, Sun, 24 Jun 2007.

Syndication is also addressed by <style scope>. Anne van Kesteren, Sun, 01 Jul 2007.

Debugging

It's really useful for debugging. It's clearly THE easiest ways to style a single element. Rene Saarsoo, Sat, 30 Jun 2007.

The attribute will still be supported, and it's use in debugging, as opposed to a production environment, is not really a reason for it to be considered conforming. Lachlan Hunt, Sat, 30 Jun 2007.

I think debugging is an important usecase. Your debugging tool might display an error for incorrect and that would prevent you from using the style= attribute. Anne van Kesteren, Sun, 01 Jul 2007.

Graphs and diagrams

One example is Tag clouds (like in Flickr).

There are alternatives for tag clouds, which are being investigated by the microformats community. (Tagcloud brainstorming.) Lachlan Hunt, Sat, 30 Jun 2007.

Another example is Bar graphs (like in this page).

This is already solved using the new <meter> element. Lachlan Hunt, Sat, 30 Jun 2007.

Separation of style and structure by style attribute

[The style attribute] keeps the separation between style and structure; by filtering out everything called "style" your structure and content remains. Håkon Wium Lie, Sun, 24 Jun 2007.

The other benefit of stylesheets is to separate the content from the presentation, but if my application is PHP (or even XSLT! where @style has also come in handy to me!) that separation doesn't benefit me more than it hurts. Jon Barnett, Mon, 25 Jun 2007.

Backwards compatability of scoped style

Yes, the @scoped attribute does look quite interesting, but how many years do we have to wait until the browsers support it? - will it make it into IE10 for instance? Craig Francis, Sun, 24 Jun 2007.

Also, that [style attribute] draft's new rules for @style are backward compatible, where I don't see how
<style scoped></style>...
is backward compatible: today's browsers would apply those styles to the entire document. Am I missing something? Jon Barnett, Mon, 25 Jun 2007.

<localstyle> element

As many have pointed out, style element with scoped attribute is not backwards compatible. To resolve this problem, I propose a new element instead. e.g. <localstyle> or <scopedstyle>. Authors can use HTML comments to hide contents of the new element from older user-agents. Rene Saarsoo, Tue, 03 Jul 2007.

Style attribute has no media information

The problem with the style= attribute, as opposed to the <style> element. Is that it encourages media specific style sheets. As the media for the style= attribute is automatically "all". It also does not allow for alternate style sheets. The <style> element in HTML5 handles both. Anne van Kesteren, Sun, 24 Jun 2007.

In most most cases where @style is used, it's used in a way that the media

doesn't matter... if I wrote
    I don't care whether the media is paged, on screen, or printed. If the media is aural, that property is irrelevant. I imagine that most use cases for "style" are like that. I'm aware that if I wanted alternate stylesheets, I would need to take those styles out into a stylesheet. Jon Barnett, Mon, 25 Jun 2007. Most stylesheets included with non-scoped <style> or with <link> do not set media-scoped styles. @media rules are rare, and <link rel="stylesheet"> rarely specifies a media attribute. Given this, there is little evidence that authors will be more likely to scope their styles to particular media just because they have a mechanism that allows it. And indeed, for many styles, doing so is not needed to achieve media-independent styling. For instance, property definitions like "font-weight: bold" or "font-size: 2em" don't really need to be set differently between different visual media and are irrelevant to non-visual media. Including both style="" and <style scoped> would allow a convenient way to set local styles that degrades gracefully, as well as a less backwards compatible but more powerful mechanism that allows media selection and full rules with selectors. - Maciej Stachowiak, Mon, 2 Jul 2007.

    Extending the style attribute

    I think the CSS3 WG on the style attribute syntax is actually a more elegant approach (and easier to understand for authors) than the scoped style element. The scoped style element has a lot of opportunities to be misunderstood by implementors and authors alike. I don't think [scoped style] adds anything that the CSS3 style attribute doesn't already make possible (and some CSS3 is already being implemented by some early-adopter implementations). In contrast, the changes to the style attribute will be easy for everyone to understand. Robert Burns, Sun, 24 Jun 2007.

    Why bring back the font element?

    WYSIWYG editors use font tags because that's what IE does generate with the execCommand, but what it does generate is or (well, in uppercase and without quotes, but let's forget that for a moment), it doesn't understand so if any editor wants to work the way proposed in this spec and also being used by IE users, then it will need to do all the work to format the text, so in the end it can do it with font or with any other tag, being it for example or whatever you like. Alfonso Martínez de Lizarrondo, Sun, 24 Jun 2007.

    Bringing back the font element to HTML 5 might send a wrong signal to web authors. There have been a lot of educational work done about the bad sides of font element. Rene Saarsoo, Sat, 30 Jun 2007.

    The idea of making style="" only apply to was that we could attach the stigma of to style="". Ian Hickson, Thu, 3 May 2007.

    WYSIWYG signature might become the new Transitional doctype

    • [19:53] <zcorpan> Hixie: the result will be that those who hand-write templates will add the <meta> to claim that they are wysiwyg. so they can use style="" and pass validation
    • [19:53] <zcorpan> q.v. transitional doctype and target=""
    • [19:53] <zcorpan> *or* they will come up with uglier hacks
    • [19:53] <zcorpan> q.v. adding target="" with javascript
    • [19:56] <zcorpan> so if we find that we need to allow something for wysiwyg, it has to be conforming for anyone (yet we can discourage or say that authors SHOULD NOT do it or whatever, but trying to force them not to will lead to the same path as target="" situation today, i think)
    • [19:59] <zcorpan> or say that it isn't conforming but say that wysiwyg tools can emit it anyway
    • [20:00] <zcorpan> what i'm saying is that the wysiwyg meta tag is the new transitional doctype

    IRC log, Fri, 4 May 2007.

    A proposal by Henri Sivonen

    1. Make style="" a global attribute. For the purposes of document conformance, make it conforming on all documents regardless how they came to being.
    2. Include an informative paragraph about how media-dependent use of style="" is bad.
    3. make the conformance checker emit a warning (at most one per document) that paraphrases the informative paragraph when the conformance checker sees a style="" attribute.
    4. make the WYSIWYG signature suppress the warning.
    5. is either made non-conforming or made a strictly inline element with the attribute color (to avoid cruft).

    Henri Sivonen, Fri, 4 May 2007.

    Research

    According to Hixie's research the style attribute is used on ~ 13.5% of <a> elements, 10.9% of

    elements and 10.6% of <img> elements.