---I've already said that for generic, planned styling stylesheets are exactly what you want (though I'd like to see the ability to do textual rearrangement and modification in the right-hand-sides, rather than just text presentation attribute changes).
Your example, however, contains something totally unplanned and non-generic. The reader reasonably knows that H1 appearance is controlled by the stylesheet and will be done in an appropriate way. She has no reason to expect, when reading the text, that a particular paragraph has been styled by name. I still think that's broken - if you're going to apply special styling to a named element instance, there should be some indication at the point of the instance.
--- | | Say you have a CD-ROM with HTML text on it; what are you going to | use, STYLE attributes or IDs? If you use STYLE attributes then -- | you lose. That is, when you want to change the appearance, good luck. | On the other hand, if you do The Right Thing and use IDs or a style | attribute whose declared value is restricted to NAMEs (see below), then | you're in good shape: you can simply change the contents of your off- | board stylesheet, and off and away you go!---What has CD-ROM-ness got to do with anything? It shouldn't change the interpretation of STYLE="{font.size: 14}" that I can think of.
--- | | There's no way you can reuse that styling rule - the ID is required | to be unique, so it cannot affect any other element anywhere. | | You can resuse it by adding additional selectors to the LHS of the rule. | Of course you can use CLASS instead of ID, or perhaps, if you really want | a STYLE attribute, then restrict its declared value to be NAME or NAMES only.---Umm. OK, I guess I'll grant that that's reuse. Whether it's helpful or not depends on whether the applied styling is common or specific and is useful anywhere else, but there's the potential for gain.
--- | | (1) is an arguable goal (hence the arguing we've been doing). I | don't know whether (2) is important or not in your implementation - | again, I can imagine impleemntations where it made no difference at all. | I don't see (3) as interesting as stated (who cares about merging style | rules when you're just adding additional styles to whatever the rules | would have applied anyway?), but, again, I don't know your | implementation. (4) doesn't make sense to me (why do you care about | predicting processing requirements) and seems trivial compared to other | things you might encounter on the fly. | | You don't understand because you haven't attempted to implement support | for any of the ideas you are proposing. Or, if you have, then you haven't | attempted to make your implementation efficient.---No, I haven't built a browser, though I have walked parse tree from time to time and queried the occasional dictionary. If you entered those as objections on an IEEE standards ballot, though, you'd need to present a wee bit more detail to convince people the issues were universal and inherent.
--- | Information, including styling information, that is specifically local | to an element should be with that element. | | I disagree. Others do too. I'd suggest you read "Making Hypermedia Work" | by S. DeRose and D. Durand if you want to see the big picture. | | BTW, if you don't care about typing, then why are you arguing these points | at all? If the user isn't typing in style data, then there is absolutely | no reason to have the style attribute as its been discussed thus far (i.e., | putting the rule in the attribute). If the user isn't typing the document, | then the model can be an abstraction which is serviced by the implementation | in a way which doesn't permit use of local style rules embedded in the tags.---Because, as a potential consumer of the product, it "feels wrong" to me. Stylesheets feel right, but the inability to put information locally, when appropriate, feels wrong. Intuition, based on experience, tells me I will want to put my fingers where your restriction says I can't...
scott
-- scott preece motorola/mcg urbana design center 1101 e. university, urbana, il 61801 phone: 217-384-8589 fax: 217-384-8550 internet mail: preece@urbana.mcd.mot.com