RE: Authoring tool specific attributes in XHTML 1.0+

Hello,

if you need such an attribute,

simply use your own XHTML M12N document type which includes a module that
adds the required attribute in the desired attribute collection. That's the
legal and working way to extend XHTML with new elements and attributes
yourself.
An Example of a module adding new elements can be found in the
Recommendation of XHTML M12N.

Another way of storing tool specific informations in XML documents are
processing instructions.

Greetings

Christian Wolfgang Hujer


> -----Original Message-----
> Hi
>
> I would like to propose that an additional "special" attribute (such as
> "xml:app") be available for use on all elements in XHTML, which
> can be used
> for "authoring tool specific purposes", whilst still allowing the document
> to be validated.
>
> Here's a real-world example:
>
> When a web designer uses a tool such as Adobe GoLive to insert an
> image into
> an HTML page, the tool allows the designer to select the source
> "asset" and
> the
> target file and optimization settings.  In practice, this is
> really powerful
> since the source assets are high resolution, may be shared
> between projects
> and are unoptimized (and may consist of several layers if they
> are Photoshop
> files, for example), but the target files are in a "flattened" web browser
> format (gif/jpeg/png) and are "optimized for the web".  Indeed, if you
> resize an image on the page, the tool regenerates the target image.
>
> But to do this the tool has to store additional information in the image
> element.  Which unfortunately means that validating the document
> will fail.
>
> It would be ideal if this tool-specific information could be put in the
> value of a special attribute which UAs will ignore (and maybe even other
> authoring tools if some convention were agreed based on the first few
> characters of the value, or something).  But, crucially, the
> document would
> still be valid XHTML.
>
> There are lots of other examples where an additional attribute would be
> useful.  Especially with media objects that have a "source project"
> associated with them.  And also in other cases, such as where pages are
> constructed in the authoring tool from a number of source page
> "components".
>
> If the DTD could be extended to allow the storage of an authoring tool
> specific attribute, as I propose, then the creators of authoring
> tools would
> not need to make up proprietary attributes and tags.
>
> I suppose I could always tweak the DTD I use for validation.  But does it
> make sense to validate, if I am validating against a different DTD from
> everybody else?!
>
>
> Greetings
>
> nik
>
>
> ----- Original Message -----
> From: "Christian Wolfgang Hujer" <Christian.Hujer@itcqis.com>
> To: "Matt Brooks" <matt@mbjlp.com>; <www-html@w3.org>
> Sent: 05 September 2001 22:15
> Subject: RE: "alt" attribute required by XHTML 1.0
>
>
> > Hello Matt,
> >
> > you were ignoring the following facts (most of this was already
> said, but
> I
> > wanted to write a full list that I can recycle... ;) (It is great of you
> > that at least you tried to validate, many so-called "web designers" or
> "HTML
> > programmers" (ouch!) even do not know that something like validation
> exists
> > at all...):
> >
> > - requirement of the alt attribute for the <img/>-element is
> not new. For
> > HTML 4.01, HTML 4, HTML 3.2, HTML 3.0 and HTML 2.0 I am sure they also
> > required the alt attribute for valid documents. For HTML+ and HTML I am
> not
> > sure, neither I am for ISO-HTML, but since ISO-HTML is the most
> restrictive
> > HTML I've ever seen (you may not use H3 after H1, and you may not use H2
> if
> > you didn't use H1 before...), I believe it also requires the
> alt-Attribute.
> >
> > - that spacer-Images are *not* what HTML-Cracks use for
> positioning since
> > this won't work as intended, anyway.
> >
> > - HTML is a language for description of document semantics, for
> layout use
> > CSS
> >
> > - that people are using text browsers if they are freaks using lynx or
> using
> > small devices that cannot display fancy graphics
> >
> > - that there are blind people surfing the web using speech browsers
> >
> > - that validation generally is a good idea
> >
> > - that if you do not write valid HTML, you are not writing HTML at all,
> you
> > are just writing some SGML or XML nonsense which the web
> browsers do their
> > best to display
> >
> > - that the main attribute for Tooltip display is the title attribute, so
> you
> > could try to override the alt="" empty tooltip with title="" for no
> tooltip
> > in some browsers
> >
> > - that alt="" won't display a tooltip in most browsers anyway
> >
> >
> > There is not alternative to valid documents except for the following:
> > - your XSLT transformation that generates your HTML documents
> is not fully
> > XSLT 1.1 compliant, so no namespace cleanup is performed and you may get
> > additional namespace attributes
> > - you are using a language mix of HTML and another namespace like SVG,
> SMIL
> > or MathML
> > Neither is the case with your documents.
> >
> > For your <a name="label"/>-problem:
> > - The correct writing is <a id="label"/>
> > - It is no problem to include <a id="label"/> in block elements
> only, try
> > using <div><a id="label"/></div> if nothing else helps, but usually <a
> > id="label"/> comes in context of a document structure, so a
> good position
> > would be within a <hn/> or <dt/> element.
> > You should include div {margin:0;padding:0;} in your stylesheet to avoid
> > problems with older browsers using <div/> like <p/>.
> >
> >
> > Believe me, it is perfectly possible to write documents that
> > - use "latest" features like ECMAScript ("JavaScript"), Java
> Applets, SVG
> > Graphics and CSS Level 2 Layout
> > - are fully backwards compatible to nearly every browserš
> > - display great on new browsers and old browsers
> > - display great on text browsers like Lynx or w3m
> > - look as if they had frames in IE5, 5.5, 6 and Netscape6 / Mozilla with
> the
> > use of the CSS Level 2 overflow property though they do not use the
> Frameset
> > document type, so they are viewable with browsers that aren't capable of
> > displaying frames
> > - are valid XHTML Basic 1.0, XHTML 1.0 Strict or XHTML 1.1.
> >
> > If you have questions or problems regarding this, feel free and drop a
> line
> > to me.
> >
> > I think that frames will die anyway, XHTML 1.1 does only have
> one document
> > type, not three, that corresponds to strict; Transitional and
> Frameset are
> > likely to die. XHTML Basic doesn't support Frames, too, of course.
> >
> > šNetscape 4 and elder require empty element tags for empty
> elements to use
> > whitespace before the /, so write <br /> instead of <br/>;
> > javax.swing.text.JEditorPane based browsers like HotJava or self-made
> > Java-written browsers have a bug and will display the / in empty element
> > tags. Always use ASCII only as encoding, this is UTF-8
> compatible since it
> > only uses characters with numbers 0-127, and omit the XML declaration,
> which
> > only is allowed if you use UTF-8 for encoding, which is the case if you
> use
> > ASCII. Encode all characters that are not ASCII-characters (US-ASCII-7)
> like
> > Umlauts with their corresponding entites.
> >
> >
> > Greetings
> >
> > Christian
> >
> > -----Original Message-----
> > From: www-html-request@w3.org
[mailto:www-html-request@w3.org]On Behalf Of
> Matt Brooks
> Sent: Wednesday, September 05, 2001 6:43 PM
> To: www-html@w3.org
> Subject: "alt" attribute required by XHTML 1.0
>
>
> I was surprised to see that the ALT attribrute is required by the XHTML
1.0
> Transitional DTD. I was going to use XHTML 1.0 Transitional in a web
> development project, but have now changed my mind because the ALT
attributes
> are not needed on every image.
>
>  - Matt
>
> -----Another Original Message-----
> No, because "" produces an empty (but displayed) tooltip in some browsers.
> This is unacceptable.
>

Received on Friday, 14 September 2001 11:08:27 UTC