Re: Splitting up the spec

On Mon, Nov 24, 2008 at 4:56 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Sat, Nov 22, 2008 at 9:39 PM, Jim Jewett <jimjjewett@gmail.com> wrote:
>> Jonas Sicking wrote:

>>> if I don't care about CSS I won't care about <style>,
>>> <div>, <span>, rel=stylesheet, or style="...".

>> To me, that case is a good argument for the split.

>> The Markup Semantics spec should define them, so that you can look
>> them up for reference, if you find them elsewhere.  You probably won't
>> use them, but the definitions are short enough that they won't be a
>> problem.

> I'm not following. Should we have those tags defined in the 'language
> spec'? If so, why? Given that not all users need it why not split them
> out into a separate spec?

I'll try to give the Markup Vocabulary section for those, to make this
more concrete.

--------------------

The div section (currently 4.12.2) is actually pretty good.

I would remove the DOM interface, only because I would remove all DOM
information to a related spec.  But (at least for this element) it is
sufficiently short and declarative that I wouldn't fight too hard over
that decision.

""""
The div element represents nothing at all. It can be used with the
class, lang/xml:lang, and title attributes to mark up semantics common
to a group of consecutive elements.
"""

add:

"It is therefore often the most appropriate placeholder element when
hooks are needed for additional styling or behavior."

---------------------

span has about the same comments as div.

----------------------

rel=stylesheet, 5.11.3.15 Link Type "stylesheet"

The first four (short) paragraphs are OK.  I think some rewording
might help, but don't have a concrete proposal at this time.

The Quirk paragraph should be removed to a secondary spec.  (Whether
that is User Agent, Processing,  Error Correction, or Parsing would
depend on the breakdown within that secondary portion; it is possible
that all four would be together.)

--------------------

style=

Again, I would remove the DOM paragraph to a separate spec which
covered processing or rendering.

I think the first four paragraphs could be simplified once styling is
removed to that spec, but ... that is step 2.

In the example:
"""
In the following example, the words that refer to colors are marked up
using the span element and the style attribute to make those words
show up in the relevant colors in visual media.
"""
-->
"""
In the following example, the words "green" and "blue" are marked up
using the span element and the style attribute.  A visual User Agent
which supports styling would typically render those words in the
relevant colors.
"""

----------------------------------------

The style element, 4.2.6:

Again, remove the DOM interface section.

The first two paragraphs of text are fine.

The paragraph about unknown type should probably go to the processing
or error-correction spec.

Remove the following sentence about User Agents to the spec that
handles rendering or processing:  "User agents must apply the styles
to views while their state match the listed media, and must not apply
them otherwise. [DOM3VIEWS]"

The next three paragraphs (scoped and title attributes) are OK.

Remove the paragraph starting "All descendant elements must be
processed ..." to the processing or rendering spec.

"""
Note: This specification does not specify a style system, but CSS is
expected to be supported by most Web browsers. [CSS21]
"""
Because of the defaults and the style attribute, it sort of does
specify a style system.  I would change "specify" to "require support
for".

The final two paragraphs and all of section 4.2.7 should be removed to
the rendering or processing spec.



>> Please look at http://www.w3.org/TR/REC-html40/present/styles.html
>> How much of that still seems like it should really be in HTML itself?

>> To me, it looks like large portions really ought to have been left for CSS
>> to define.  For example, Content-Style-Type appears in that document,
>> and one other in my entire cache.  ... That HTML section provides
>> (normative?) information about how to write a CSS style, but you still
>> need to go to the CSS spec anyhow to get a list of valid property values.

> IMHO all the parts about elements and attributes need to be in the
> HTML spec. Content-Style-Type definitely needs to be in the HTML spec,
> otherwise you have no idea how to interpret the text inside the
> <style> element.

For markup purposes, the text is opaque.  All we need to know is which
characters can not occur, because they would close the element.

Unfortunately, that small amount of information gets sort of drowned
out by the large amounts (non-normative?) information that got placed
there in practice.

If non-default Content-Style-Type is ever used in practice, then it
does need to be in the HTML processing or User Agent spec -- but it
isn't part of the markup vocabulary.

> Section 14.6 looks to me like the only part that doesn't belong in the
> HTML spec, as it is not specific to HTML at all.

I would say the same about 14.1;  that seems to be the motivation and
use cases for a styling language, but it isn't specific to HTML.  (And
if there was normative infromation there, it was easily missed.)

Section 14.2.2 efffectively makes the syntax of HTML undefined, until
after you have determined the default stylesheet language, and
supported it well enough to tell when to stop parsing it.  (The
current spec just assumes CSS, which is at least a bounded problem.)

Section 14.2.3 has the same formal problem of not specifying how to
tell when the styling content has ended, unless you support the
styling langauge.

It also wasn't entirely clear whether the examples given need to be
supported, at least by a parser.  (So does HTML require a certain
level of CSS support?)

Is 14.2.4 (media types) really part of HTML?  Or is it enough for HTML
that the media types are opaque strings, whose meanings will be
defined by the styling language that only some HTML consumers need to
understand?

14.3 talks about how to combine style sheets; this mostly seems like
information that should have been delegated to the style language.
(The HTML5 group may need it in the rendering spec, because of the de
facto reliance on CSS, but it shouldn't be in the markup vocabulary.)

> Section 14.4.2 also
> looks misplaced, but it doesn't contain any normative text as far as I
> can tell.

I would say that all of 14.4 ought to be delegated to the stylesheet spec.

It looks to me as if the spec is saying "The stylesheet langauge
defines cascading, but HTML also defines a normative requirement that
you do X, Y, and Z."  It isn't clear which of those requirements would
constrain an alternative stylesheet langauge as well, if it were to be
used with HTML.

I *think* 14.5 is just informative, and echoing the earlier normative
language that:
"""
User agents that don't support style sheets, or don't support the
specific style sheet language used by a STYLE element, must hide the
contents of the STYLE element. It is an error to render the content as
part of the document's text. Some style sheet languages support syntax
for hiding the content from non-conforming user agents.
""'

> So lets put it the other way around. Say that the CSS 1 spec would
> have looked the way it does, but it also defined the rel and name
> attributes for the <link> tag, and how they are used to link
> alternate, preferred and persistent stylesheets to HTML. Don't you
> think that someone would have said "That stuff doesn't belong in the
> CSS spec, that is HTML specific, CSS doesn't define how a specific
> markup language should link to CSS"?

I think that the rel/name stuff is part of CSS.  That it gets
represented specifically as <link rel=... name=... title=...> is part
of HTML, but what to do with those parameters is part of CSS.

> Another, and I think more important point is this. How much harm has
> the stylesheets part of HTML4 caused?

Has the "other style languages OK too" part seen much support in
practice?  Or have those languages needed to design themselves around
the CSS integration?

It has caused some problems for user agents that don't do styling,
though I'm not sure how to cleanly help them so long as <style> and
style= are still there.

> I can't see anything in there that mentions CSS features that is
> normative. Though I admit I could have missed such a place as I didn't
> spend much time looking. All the examples look non-normative though.

The very fact that we aren't sure which parts are normative (or when)
is a strong indication that the spec is underdefined -- exactly what
we hoped to avoid by conglomerating this time around.

-jJ

Received on Monday, 24 November 2008 16:54:17 UTC