Nicolas Goaziou writes: > Does every possible attribute follow attribute="value" pattern? Aren't > there single keywords?
In XHTML it does, and there aren't. In HTML you can use some "minimized" attributes, but in XHTML they have their own names as values, e.g. nowrap="nowrap". > If they are that regular, we can indeed walk the > plist like a list and change > > (:key1 val1 :key2 val2 ...) > > into > > key1="val1" key2="val2" ...and let the user worry about getting them right. That's my suggestion, FWIW. > If there are irregular keywords, the export back-end needs to know about > them. XML doesn't do `irregular'. :) XHTML is also fussy about quoting attribute values, and about escaping special characters as HTML entities, including the ampersand (&), and including inside attribute values. I'm guessing the exporter already does the right thing here. Since values may legitimately contain double quotes, one thing the back-end *does* need to know about is to put those in single quotes: :title This is a "pop-up" text title='This is a "pop-up" text' > Also, if attributes are provided, I assume defaults should be ignored > altogether. Or do we need to create the union between default values and > provided attributes? If I understand the question correctly, I think the union is the correct answer, with provided attributes overwriting defaults for the same attributes. In the example we started with, the defaults would create <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides"> If the user specifies #+attr_html: :border 2 :rules all :frame border :title My table I would expect the result <table border="2" cellspacing="0" cellpadding="6" rules="all" frame="border" title="My table"> You may want a second opinion on all this -- I'm no (X)HTML guru and I've never written an exporter. But it seems to me the pure plist form would less confusing to the user than a split syntax, and easier to maintain, as well. Yours, Christian
