mirror of
https://github.com/ezyang/htmlpurifier.git
synced 2024-12-23 00:41:52 +00:00
e4e981b6f1
git-svn-id: http://htmlpurifier.org/svnroot/htmlpurifier/trunk@1067 48356398-32a2-884e-a903-53898d9a118a
33 lines
1.6 KiB
Plaintext
33 lines
1.6 KiB
Plaintext
|
|
Is HTML Purifier Strict or Transitional?
|
|
[rename/deprecation pending]
|
|
|
|
Despite the fact that HTML Purifier professes to support both transitional and
|
|
strict HTML, it rejects a lot of attributes and elements that are actually, indeed,
|
|
valid. You can investigate progress.html to find out precisely what we
|
|
are doing to these *deprecated* attributes.
|
|
|
|
However, users have found that Strict HTML imposes some quite unreasonable
|
|
restrictions on certain things. The start and value attributes in ol and
|
|
li (respectively) perhaps are the most contested. There's is currently no
|
|
widely supported browser method short of JavaScript that can replace these
|
|
two deprecated elements. It behooves us to allow these deprecated
|
|
attributes when the output is transitional.
|
|
|
|
Fortunantely, that's the only real bugger case. The others have near-perfect
|
|
CSS equivalents, and were presentational anyway. However, the other question
|
|
pops up: should we always convert these to the CSS forms when 1. the spec
|
|
allows them anyway and 2. older browsers support them better? After all, the
|
|
whole point about CSS is to seperate styling from content, so inline styling
|
|
doesn't solve that problem.
|
|
|
|
[new material]
|
|
|
|
HTML Purifier 1.7 creates a new organizational system for deprecated attribute/
|
|
element transformations. They will be unified under the title of "Tidy", which
|
|
is what they are: cleaning up after deprecated user markup into standards-compliant
|
|
versions. There will also be a change in the default behavior (athough, to the
|
|
end user not inspecting the HTML, there will be no change: in fact, it may
|
|
work even better).
|
|
|
|
Consult the Advanced API for more details. |