From a84648cff1b7f26779fff1c7347c8364aaf04670 Mon Sep 17 00:00:00 2001 From: Jacques Distler Date: Wed, 13 May 2009 01:27:39 -0500 Subject: [PATCH] Fix Maruku Escaping Bug Sync with latest Maruku (now on github). lib/maruku/ext/math/mathml_engines/none.rb should HTML-escape the TeX source code. No it does. --- vendor/plugins/maruku/AUTHORS | 8 +- .../maruku/ext/math/mathml_engines/none.rb | 2 +- vendor/plugins/maruku/lib/maruku/helpers.rb | 6 +- .../maruku/lib/maruku/input/parse_doc.rb | 17 +- vendor/plugins/maruku/lib/maruku/version.rb | 2 +- .../maruku/tests/unittest/divs/div1.md | 46 +- .../maruku/tests/unittest/divs/div2.md | 6 +- .../maruku/tests/unittest/divs/div3_nest.md | 8 +- .../maruku/tests/unittest/inline_html.md | 31 +- vendor/plugins/maruku/tests/unittest/links.md | 17 +- .../tests/unittest/lists_after_paragraph.md | 2 +- .../maruku/tests/unittest/math/equations.md | 77 +- .../maruku/tests/unittest/math/inline.md | 4 +- .../maruku/tests/unittest/math/math2.md | 45 +- .../maruku/tests/unittest/math/table.md | 6 +- .../tests/unittest/recover/recover_links.md | 10 +- .../tests/unittest/red_tests/abbrev.html | 101 ++ .../maruku/tests/unittest/red_tests/abbrev.md | 1388 +++++++++++++++++ .../maruku/tests/unittest/red_tests/xml.html | 15 + .../maruku/tests/unittest/red_tests/xml.md | 70 + 20 files changed, 1725 insertions(+), 136 deletions(-) create mode 100644 vendor/plugins/maruku/tests/unittest/red_tests/abbrev.html create mode 100644 vendor/plugins/maruku/tests/unittest/red_tests/abbrev.md create mode 100644 vendor/plugins/maruku/tests/unittest/red_tests/xml.html create mode 100644 vendor/plugins/maruku/tests/unittest/red_tests/xml.md diff --git a/vendor/plugins/maruku/AUTHORS b/vendor/plugins/maruku/AUTHORS index da6ea5a5..e6c73e6d 100644 --- a/vendor/plugins/maruku/AUTHORS +++ b/vendor/plugins/maruku/AUTHORS @@ -1,11 +1,15 @@ +Incomplete list of contributors +------------------------------- + Code and patches from: -* [Andrea Censi](http://www.dis.uniroma1.it/~acensi) -* [Jacques Distler](http://golem.ph.utexas.edu/~distler) +* [Andrea Censi](http://www.cds.caltech.edu/~andrea/) +* [Jacques Distler](http://golem.ph.utexas.edu/~distler/) * Paul Dlug * [Ari Stern](http://www.acm.caltech.edu/~astern) * Damir Zekic (z3c) * Alexandr Mankuta (cheba) +* Nathan Weizenbaum Bug reporting, feature requests and praise: diff --git a/vendor/plugins/maruku/lib/maruku/ext/math/mathml_engines/none.rb b/vendor/plugins/maruku/lib/maruku/ext/math/mathml_engines/none.rb index 42f1df47..e44408e8 100644 --- a/vendor/plugins/maruku/lib/maruku/ext/math/mathml_engines/none.rb +++ b/vendor/plugins/maruku/lib/maruku/ext/math/mathml_engines/none.rb @@ -6,7 +6,7 @@ module MaRuKu; module Out; module HTML # or return an empty array on error # return [] # or have a string parsed by REXML: - tex = tex.gsub('&','&') + tex = tex.escapeHTML mathml = "#{tex}" return Document.new(mathml).root end diff --git a/vendor/plugins/maruku/lib/maruku/helpers.rb b/vendor/plugins/maruku/lib/maruku/helpers.rb index 052810d3..5f90c7c8 100644 --- a/vendor/plugins/maruku/lib/maruku/helpers.rb +++ b/vendor/plugins/maruku/lib/maruku/helpers.rb @@ -91,10 +91,10 @@ module Helpers raw_html = "#{raw_html}" e.instance_variable_set :@parsed_html, REXML::Document.new(raw_html) - rescue #Exception => ex + rescue REXML::ParseException => ex e.instance_variable_set :@parsed_html, nil -# tell_user "Malformed block of HTML:\n"+ -# add_tabs(raw_html,1,'|') + maruku_recover "REXML cannot parse this block of HTML/XML:\n"+ + add_tabs(raw_html,1,'|') + "\n"+ex.inspect # " #{raw_html.inspect}\n\n"+ex.inspect end e diff --git a/vendor/plugins/maruku/lib/maruku/input/parse_doc.rb b/vendor/plugins/maruku/lib/maruku/input/parse_doc.rb index 5b11725e..f4a4909a 100644 --- a/vendor/plugins/maruku/lib/maruku/input/parse_doc.rb +++ b/vendor/plugins/maruku/lib/maruku/input/parse_doc.rb @@ -198,14 +198,17 @@ Disabled by default because of security concerns. XPath.match(doc, "//*[attribute::markdown]" ).each do |e| # puts "Found #{e}" # should we parse block-level or span-level? - parse_blocks = (e.attributes['markdown'] == 'block') || - block_tags.include?(e.name) - # remove 'markdown' attribute - e.delete_attribute 'markdown' + + how = e.attributes['markdown'] + parse_blocks = (how == 'block') || block_tags.include?(e.name) + # Select all text elements of e XPath.match(e, "//text()" ).each { |original_text| s = original_text.value.strip if s.size > 0 + + # puts "Parsing #{s.inspect} as blocks: #{parse_blocks} (#{e.name}, #{e.attributes['markdown']}) " + el = md_el(:dummy, parse_blocks ? parse_text_as_markdown(s) : parse_lines_as_span([s]) ) @@ -217,7 +220,11 @@ Disabled by default because of security concerns. end } - + + + # remove 'markdown' attribute + e.delete_attribute 'markdown' + end end diff --git a/vendor/plugins/maruku/lib/maruku/version.rb b/vendor/plugins/maruku/lib/maruku/version.rb index 651ffc93..905b179f 100644 --- a/vendor/plugins/maruku/lib/maruku/version.rb +++ b/vendor/plugins/maruku/lib/maruku/version.rb @@ -19,7 +19,7 @@ #++ module MaRuKu - Version = '0.5.9' + Version = '0.6.0' MarukuURL = 'http://maruku.rubyforge.org/' diff --git a/vendor/plugins/maruku/tests/unittest/divs/div1.md b/vendor/plugins/maruku/tests/unittest/divs/div1.md index 37ae3cfa..3acd7f90 100644 --- a/vendor/plugins/maruku/tests/unittest/divs/div1.md +++ b/vendor/plugins/maruku/tests/unittest/divs/div1.md @@ -54,18 +54,18 @@ require 'maruku/ext/div'; {} # params *** Output of inspect *** md_el(:document,[ - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]), - md_el(:div,[md_par(["text"])],{},[]) + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]), + md_el(:div,[md_par(["text"])],{:label=>nil,:num=>nil,:type=>nil},[]) ],{},[]) *** Output of to_html ***
@@ -116,7 +116,29 @@ md_el(:document,[

text

*** Output of to_latex *** +text +text + +text + +text + +text + +text + +text + +text + +text + +text + +text + +text *** Output of to_md *** text diff --git a/vendor/plugins/maruku/tests/unittest/divs/div2.md b/vendor/plugins/maruku/tests/unittest/divs/div2.md index 220f4c45..38031015 100644 --- a/vendor/plugins/maruku/tests/unittest/divs/div2.md +++ b/vendor/plugins/maruku/tests/unittest/divs/div2.md @@ -6,13 +6,15 @@ require 'maruku/ext/div'; {} # params ciao =-- *** Output of inspect *** -md_el(:document,[md_el(:div,[md_par(["ciao"])],{},[])],{},[]) +md_el(:document,[ + md_el(:div,[md_par(["ciao"])],{:label=>nil,:num=>nil,:type=>nil},[]) +],{},[]) *** Output of to_html ***

ciao

*** Output of to_latex *** - +ciao *** Output of to_md *** ciao *** Output of to_s *** diff --git a/vendor/plugins/maruku/tests/unittest/divs/div3_nest.md b/vendor/plugins/maruku/tests/unittest/divs/div3_nest.md index 39b52127..c4f200d2 100644 --- a/vendor/plugins/maruku/tests/unittest/divs/div3_nest.md +++ b/vendor/plugins/maruku/tests/unittest/divs/div3_nest.md @@ -16,8 +16,8 @@ md_el(:document,[ md_el(:div,[ md_par(["this is the last warning!"]), md_par(["please, go away!"]), - md_el(:div,[md_par(["or else terrible things will happen"])],{},[[:class, "menace"]]) - ],{},[[:class, "warning"]]) + md_el(:div,[md_par(["or else terrible things will happen"])],{:label=>nil,:num=>nil,:type=>nil},[[:class, "menace"]]) + ],{:label=>nil,:num=>nil,:type=>nil},[[:class, "warning"]]) ],{},[]) *** Output of to_html ***
@@ -30,7 +30,11 @@ md_el(:document,[
*** Output of to_latex *** +this is the last warning! +please, go away! + +or else terrible things will happen *** Output of to_md *** this is the last warning! diff --git a/vendor/plugins/maruku/tests/unittest/inline_html.md b/vendor/plugins/maruku/tests/unittest/inline_html.md index 09440326..9652a921 100644 --- a/vendor/plugins/maruku/tests/unittest/inline_html.md +++ b/vendor/plugins/maruku/tests/unittest/inline_html.md @@ -37,20 +37,12 @@ Without closing: - +
This is *true* markdown text. (no par)This is a *true* markdown text. (no par) This is *true* markdown text. (par)
-The following is invalid HTML, and will generate an error: - - - - - -
This is *true* markdown text. (no par)This is *true* markdown text. (par)
- *** Output of inspect *** md_el(:document,[ @@ -68,10 +60,7 @@ md_el(:document,[ md_par(["Without closing:"]), md_html(""), md_html("
\n\tThis is *true* markdown text (paragraph)\n\n\t

\n\t\tThis is *true* markdown text (no paragraph)\n\t

\n\t

\n\t\tThis is *true* markdown text (block paragraph)\n\t

\n
"), - md_html("\n\n\n\n\n
This is *true* markdown text. (no par)This is *true* markdown text. (par)
"), - md_par(["The following is invalid HTML, and will generate an error:"]), - md_html("\n\n\n"), - md_html("
This is *true* markdown text. (no par)This is *true* markdown text. (par)
") + md_html("\n\n\n\n\n
This is a *true* markdown text. (no par)This is *true* markdown text. (par)
") ],{},[]) *** Output of to_html ***

Input:

@@ -118,7 +107,7 @@ md_el(:document,[
-

This is

+

This is a

true

 @@ -133,13 +122,6 @@ md_el(:document,[
-

The following is invalid HTML, and will generate an error:

-
HTML parse error: 
-<table>
-<td markdown="1">This is *true* markdown text. (no par)</td>
-<td markdown="block">This is *true* markdown text. (par)</td>
-</tr>
HTML parse error: 
-</table>
*** Output of to_latex *** Input: @@ -154,8 +136,6 @@ Result on span: Result alone: Without closing: - -The following is invalid HTML, and will generate an error: *** Output of to_md *** Input: @@ -168,11 +148,8 @@ Result on span: Result alone: Without closing: - -The following is invalid HTML, and will -generate an error: *** Output of to_s *** -Input:Result: Input:Result on span: Result alone:Without closing:The following is invalid HTML, and will generate an error: +Input:Result: Input:Result on span: Result alone:Without closing: *** EOF *** diff --git a/vendor/plugins/maruku/tests/unittest/links.md b/vendor/plugins/maruku/tests/unittest/links.md index fbfa7f16..f84f728f 100644 --- a/vendor/plugins/maruku/tests/unittest/links.md +++ b/vendor/plugins/maruku/tests/unittest/links.md @@ -24,7 +24,9 @@ Search on or or ask nil}), md_ref_def("google2", "http://www.google.com", {:title=>"Single quotes"}), md_ref_def("google3", "http://www.google.com", {:title=>"Double quotes"}), @@ -94,6 +100,8 @@ md_el(:document,[

Search on http://www.gogole.com or http://Here.com or ask bill@google.com or you might ask bill@google.com.

If all else fails, ask Google

+ +

And now reference-style link ID with spaces

*** Output of to_latex *** Search on \href{http://www.google.com}{Google} @@ -114,6 +122,8 @@ Inline with title: \href{http://google.com}{Google images} Search on \href{http://www.gogole.com}{http\char58\char47\char47www\char46gogole\char46com} or \href{http://Here.com}{http\char58\char47\char47Here\char46com} or ask \href{mailto:bill@google.com}{bill\char64google\char46com} or you might ask bill@google.com. If all else fails, ask \href{http://www.google.com}{Google} + +And now \href{http://images.google.com}{reference-style link ID with spaces} *** Output of to_md *** Search on Google @@ -135,8 +145,11 @@ Search on or or ask or you might ask bill@google.com. If all else fails, ask Google + +And now +reference-style link ID with spaces *** Output of to_s *** -Search on GoogleSearch on GoogleSearch on GoogleSearch on GoogleSearch on Google imagesInline: Google imagesInline with title: Google imagesInline with title: Google imagesSearch on or or ask or you might ask bill@google.com.If all else fails, ask Google +Search on GoogleSearch on GoogleSearch on GoogleSearch on GoogleSearch on Google imagesInline: Google imagesInline with title: Google imagesInline with title: Google imagesSearch on or or ask or you might ask bill@google.com.If all else fails, ask GoogleAnd now reference-style link ID with spaces *** EOF *** diff --git a/vendor/plugins/maruku/tests/unittest/lists_after_paragraph.md b/vendor/plugins/maruku/tests/unittest/lists_after_paragraph.md index 21cd2280..e593c80d 100644 --- a/vendor/plugins/maruku/tests/unittest/lists_after_paragraph.md +++ b/vendor/plugins/maruku/tests/unittest/lists_after_paragraph.md @@ -1,4 +1,4 @@ -Write a comment abouth the test here. +This should not trigger the list *** Parameters: *** {} *** Markdown input: *** diff --git a/vendor/plugins/maruku/tests/unittest/math/equations.md b/vendor/plugins/maruku/tests/unittest/math/equations.md index 8c3317e3..0cdb2b81 100644 --- a/vendor/plugins/maruku/tests/unittest/math/equations.md +++ b/vendor/plugins/maruku/tests/unittest/math/equations.md @@ -1,6 +1,6 @@ Write a comment here *** Parameters: *** -{} +require 'maruku/ext/math';{} *** Markdown input: *** $$ x = y $$ @@ -16,42 +16,69 @@ $$ *** Output of inspect *** md_el(:document,[ - md_par(["$$ x = y $$"]), - md_el(:header,["$$ x"],{:level=>1},[]), - md_par(["$$ x = y $$"]), - md_par(["$$ x = y $$"]) + md_el(:equation,[],{:label=>nil,:math=>" x = y ",:num=>nil},[]), + md_el(:equation,[],{:label=>nil,:math=>" x = y \n",:num=>nil},[]), + md_el(:equation,[],{:label=>nil,:math=>" x = y \n",:num=>nil},[]), + md_el(:equation,[],{:label=>nil,:math=>" x = y \n",:num=>nil},[]) ],{},[]) *** Output of to_html *** -

$$ x = y $$

- -

$$ x

- -

$$ x = y $$

- -

$$ x = y $$

+
x = y
x = y
x = y +
x = y
x = y +
x = y
x = y +
x = y
*** Output of to_latex *** -\$\$ x = y \$\$ - -\hypertarget{_x}{}\section*{{\$\$ x}}\label{_x} - -\$\$ x = y \$\$ - -\$\$ x = y \$\$ +\begin{displaymath} +x = y +\end{displaymath} +\begin{displaymath} +x = y +\end{displaymath} +\begin{displaymath} +x = y +\end{displaymath} +\begin{displaymath} +x = y +\end{displaymath} *** Output of to_md *** -$$ x = y $$ -$$ x$$ x = y $$ - -$$ x = y $$ *** Output of to_s *** -$$ x = y $$$$ x$$ x = y $$$$ x = y $$ + *** EOF *** - OK! +Failed tests: [:to_html] +*** Output of inspect *** +md_el(:document,[ + md_el(:equation,[],{:label=>nil,:math=>" x = y ",:num=>nil},[]), + md_el(:equation,[],{:label=>nil,:math=>" x = y \n",:num=>nil},[]), + md_el(:equation,[],{:label=>nil,:math=>" x = y \n",:num=>nil},[]), + md_el(:equation,[],{:label=>nil,:math=>" x = y \n",:num=>nil},[]) +],{},[]) +*** Output of to_html *** +-----| WARNING | ----- +
x = y x = y
x = y +x = y
x = y +x = y
x = y +x = y
+*** Output of to_latex *** +\begin{displaymath} +x = y +\end{displaymath} +\begin{displaymath} +x = y +\end{displaymath} +\begin{displaymath} +x = y +\end{displaymath} +\begin{displaymath} +x = y +\end{displaymath} +*** Output of to_md *** + +*** Output of to_s *** *** Output of Markdown.pl *** (not used anymore) diff --git a/vendor/plugins/maruku/tests/unittest/math/inline.md b/vendor/plugins/maruku/tests/unittest/math/inline.md index 1fc66afc..1599073c 100644 --- a/vendor/plugins/maruku/tests/unittest/math/inline.md +++ b/vendor/plugins/maruku/tests/unittest/math/inline.md @@ -22,9 +22,9 @@ md_el(:document,[

Here are some formulas:

    -
  • \alpha
    • +
  • \alpha
    • -
  • x^{n}+y^{n} \neq z^{n}
    • +
  • x^{n}+y^{n} \neq z^{n}

That’s it, nothing else is supported.

diff --git a/vendor/plugins/maruku/tests/unittest/math/math2.md b/vendor/plugins/maruku/tests/unittest/math/math2.md index f2e74e94..da7edd06 100644 --- a/vendor/plugins/maruku/tests/unittest/math/math2.md +++ b/vendor/plugins/maruku/tests/unittest/math/math2.md @@ -25,12 +25,7 @@ md_el(:document,[ md_el(:equation,[],{:label=>nil,:math=>" \\gamma ",:num=>nil},[]) ],{},[]) *** Output of to_html *** -
(1)α
\alpha - -
α
\alpha - -
β
\beta -
γ
\gamma
+
α\alpha(1)
α\alpha
β\beta
γ\gamma
*** Output of to_latex *** \begin{equation} \alpha @@ -52,45 +47,9 @@ md_el(:document,[ + OK! -Failed tests: [:to_html] -*** Output of inspect *** -md_el(:document,[ - md_el(:equation,[],{:label=>"eq1",:math=>"\t\\alpha\n\n",:num=>1},[]), - md_el(:equation,[],{:label=>nil,:math=>"\t\\alpha\n\n",:num=>nil},[]), - md_el(:equation,[],{:label=>nil,:math=>" \\beta\n",:num=>nil},[]), - md_el(:equation,[],{:label=>nil,:math=>" \\gamma ",:num=>nil},[]) -],{},[]) -*** Output of to_html *** ------| WARNING | ----- -
(1) \alpha - -
\alpha - -
\alpha - -
\alpha - -
\beta -
\beta -
\gamma
\gamma
-*** Output of to_latex *** -\begin{equation} -\alpha -\label{eq1}\end{equation} -\begin{displaymath} -\alpha -\end{displaymath} -\begin{displaymath} -\beta -\end{displaymath} -\begin{displaymath} -\gamma -\end{displaymath} -*** Output of to_md *** - -*** Output of to_s *** *** Output of Markdown.pl *** (not used anymore) diff --git a/vendor/plugins/maruku/tests/unittest/math/table.md b/vendor/plugins/maruku/tests/unittest/math/table.md index d9397396..eaac2ae8 100644 --- a/vendor/plugins/maruku/tests/unittest/math/table.md +++ b/vendor/plugins/maruku/tests/unittest/math/table.md @@ -1,6 +1,6 @@ Write a comment here *** Parameters: *** -{} +require 'maruku/ext/math';{:html_math_engine => 'itex2mml' } *** Markdown input: *** $\alpha$ @@ -13,8 +13,8 @@ md_el(:document,[ md_html("
\n\t$\\alpha$\n\t\n\t\t\n\t\n
$\\beta$
") ],{},[]) *** Output of to_html *** -\alpha - +
\beta
α +
β
*** Output of to_latex *** diff --git a/vendor/plugins/maruku/tests/unittest/recover/recover_links.md b/vendor/plugins/maruku/tests/unittest/recover/recover_links.md index cec62c96..530309fc 100644 --- a/vendor/plugins/maruku/tests/unittest/recover/recover_links.md +++ b/vendor/plugins/maruku/tests/unittest/recover/recover_links.md @@ -4,15 +4,15 @@ This shows how Maruku recovers from parsing errors *** Markdown input: *** Search on [Google images][ GoOgle search ] *** Output of inspect *** -md_el(:document,[md_par(["Search on Google imagesGoOgle search ]"])],{},[]) +md_el(:document,[md_par(["Search on ", md_link(["Google images"],"google_search")])],{},[]) *** Output of to_html *** -

Search on Google imagesGoOgle search ]

+

Search on Google images

*** Output of to_latex *** -Search on Google imagesGoOgle search ] +Search on Google images *** Output of to_md *** -Search on Google imagesGoOgle search ] +Search on Google images *** Output of to_s *** -Search on Google imagesGoOgle search ] +Search on Google images *** EOF *** diff --git a/vendor/plugins/maruku/tests/unittest/red_tests/abbrev.html b/vendor/plugins/maruku/tests/unittest/red_tests/abbrev.html new file mode 100644 index 00000000..37732fa3 --- /dev/null +++ b/vendor/plugins/maruku/tests/unittest/red_tests/abbrev.html @@ -0,0 +1,101 @@ + + + +WebKit (Safari 3.1) and the CSS @font-face declaration + +

WebKit (Safari 3.1) and the CSS @font-face declaration

+ +

I’m a big fan of typography in general. If you check out my homepage or my contact elliottcable page, and you’re using Safari/WebKit or Opera/Kestrel, you’ll notice the typefaces (fonts, as colloquialized) are very non-standard. (As of this writing, I’m using Museo and Diavlo heavily on both.)

+ +

The internet has not be a friendly place for typohiles like myself, up to this point, at least. One might even say it was a frightful, mentally scarring environment for those akin to yours truly. We’ve been restricted to reading page after page after page on day after day after day for year after year after year abominations of markup and design enslaved by the horrible overlords we know as Lucida, Verdana, Arial, Helvetica, Geneva, Georgia, Courier, and… dare I invoke ye, thou my terrible overlord? Times New Roman.

+ +

Wherefore art thou, my glorious Archer? And thee as well, my beautiful Garamond? The technical restrictions of that horrible monster we know as the Web Browser hath forced us all too long to use those most banal, those most common, and those most abused, out of all of the typefaces of the world.

+ +

All hyperbole aside, I’m extremely happy to see the advent of a standard @font-face declaration in CSS. Internet Explorer first implemented a crutched, basic version of this way back in version 4, but nothing ever really came of it - their decision to create the proprietary .EOT format to appease overly restrictive type foundries’ worries about intellectual property (aka. the cold, hard dominatrix that we know only as Ms. Profit) truly and completely killed that initial attempt at bringing astute typography and it’s advocates to the web. This new run at @font-face by an established, trusted, and open group (the W3C itself, responsible for helping to make much of what we use as designers on the web standard and cross-system compatible) has a much better chance, in my humble opinion - and I am quite looking forward to the consequences if it succeeds.

+ +

Now, onwards to the topic of my post as declared in the header (yes, I know, a slow start - but it’s an interesting topic with an interesting history!). WebKit, the open source rendering engine behind the wonderfulness that is Safari, and how it handles the ‘new’ @font-face declaration. No, it’s not really ‘new’, but yes, it feels like it is.

+ +

To put it simply, and to be very blunt, it’s broken.

+ +

The CSS spec section for @font-face is very specific - typefaces are to be selected based on a wide array of criteria placed in the @font-face declaration block itself. Various textual CSS attributes may be defined within the @font-face declaration, and then they will be checked when the typeface is referred to later in the CSS. For instance, if I have two @font-face declarations for the Diavlo family - one for regular text, and one for a heavier weighted version of the typeface - then I later utilize Diavlo in a font-family: attribute, it should refer to the basic Diavlo font defined in the first @font-face. However, if I were to do the same, but also specify a heavy font-weight:, then it should use the heavier version of Diavlo. To place this example in code:

+ +
@font-face {
+  font-family: 'Diavlo';
+  src: url(./Diavlo/Diavlo_Book.otf) format("opentype");
+}
+
+@font-face {
+  font-family: 'Diavlo';
+  font-weight: 900;
+  src: url(./Diavlo/Diavlo_Black.otf) format("opentype");
+}
+
+h1, h2, h3, h4, h5, h6 {
+  font-family: 'Diavlo';
+  font-weight: 900;
+}
+
+div#content {
+  font-family: 'Diavlo';
+}
+ +

As you can see, my headings should use the typeface defined in Diavlo_Black.otf, while my body content should use Diavlo_Book.otf. However, in WebKit, this doesn’t work - it completely ignores any attribute except font-family: and src: in a @font-face declaration! Completely ignores them! Not only that - not only that - it disregards all but the last @font-face for a given font-family: attribute string!

+ +

The implication here is that, to make @font-face work as it is currently implemented in WebKit (and thus, Safari 3.1), I have to declare completely imaginary, non-existent type families to satisfy WebKit alone. Here’s the method I have used in the places I current implement @font-face:

+ +
@font-face {
+  font-family: 'Diavlo Book';
+  src: url(./Diavlo/Diavlo_Book.otf) format("opentype");
+}
+
+@font-face {
+  font-family: 'Diavlo Black';
+  src: url(./Diavlo/Diavlo_Black.otf) format("opentype");
+}
+
+h1, h2, h3, h4, h5, h6 {
+  font-family: 'Diavlo Black';
+}
+
+div#content {
+  font-family: 'Diavlo Book';
+}
+ +

Isn’t it horrible? Seriously, my eyes, they bleed. There’s lots of problems with this far beyond the lack of semanticity when it comes to the typeface names… let me see how many ways this breaks the purpose of @font-face:

+ +
    +
  • +

    You remove a large element our control over the display of the page.

    + +

    As soon as we begin to use @font-face in our page, we can no longer make any use of any other textual control attribute - font-weight:, font-style:, and font-variant: are no longer available to us, because they no longer correctly map to technical typeface variant/features.

    + +

    Also, many default elements are destroyed, unusable, without ‘fixing’ - for instance, <b> would have no effect in a page styled for WebKit as above; We would have to specify something like b {font-family: 'Diavlo Black';} - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes?

    + +

    If we want to use Javascript to modify the display of the content, we can’t simply adjust the mentioned textual control attributes - we have to know and change the entire font-family: array of strings.

    +
    • + +
  • +

    You make us very wet.

    + +

    And by wet, I mean ‘not DRY’. What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typeface’s bastardized name.

    +
    • + +
  • +

    You remove our user’s user choice, and waste bandwidth.

    + +

    Since the names refer to families that don’t, in fact, exist, the browser can’t override the declaration with a user’s installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser won’t use that - it doesn’t know to use ‘Diavlo’, which the user has installed, because it was told to use ‘Diavlo Black’, which no user in the entire world has installed on their computer.

    +
    • +
+ +

This whole thing is rather worrying - I’ve heard Opera has @font-face support, though I haven’t had time to test this myself, so I don’t know if it actually does - or, for that matter, if it does it ‘correctly’, or has the same problems as WebKit. But either way, WebKit is one of the first two implementations to ever attempt to support @font-face (Microsoft’s unrelated @font-face declaration notwithstanding) - I really don’t want to see it’s early mistakes carried on to FireFox in a few years, and then Internet Explorer a few decades after that. That will leave us stuck with this broken system forever, as it has been demonstrated time and time again that if nobody else supports an old standard correctly, a newcomer to the standard will not do it correctly either. I for one would really, really, hate that.

+ +

In summary… come on, WebKit team, this isn’t like you - you’re always the ones with the closest-to-standard implementation, and the cleanest code, and… hell, overall? Webkit is the most secure/fastest browser available. But this is making me lose my faith in you, guys, please get it right. You’re pioneering a leap into the future when it comes to the Web - this is as important, or more important, than Mosiac’s allowing of images was.

+ +

To put it succinctly - don’t fuck this up, y’all.

+
  1. +

    These are fonts by Jos Buivenga, quite the amazing person. His (free) fonts are, uniquely, released for use on the web in @font-face declarations - unlike the vast majority of other (even free to download) typefaces, which have ridiculously restricting licenses and terms of use statements. Props, Jos - you’re a pioneer, and deserve recognition as such.

    +↩
  2. +

    To give Microsoft a little credit, something I rarely do… Yes, I’m aware Microsoft submitted EOT to the W3C as a proposal - the problem isn’t with their attempts to make it non-proprietary, but with the basic concept of making typefaces on the web DRMed. Look what such attempts have done to the music and video industry - simply decimated it. Do we really want to see the same thing happen to our beloved medium as typography moves into the 21st century?

    +↩
\ No newline at end of file diff --git a/vendor/plugins/maruku/tests/unittest/red_tests/abbrev.md b/vendor/plugins/maruku/tests/unittest/red_tests/abbrev.md new file mode 100644 index 00000000..cef3e28c --- /dev/null +++ b/vendor/plugins/maruku/tests/unittest/red_tests/abbrev.md @@ -0,0 +1,1388 @@ +Write a comment here +*** Parameters: *** +{} # params +*** Markdown input: *** + +WebKit (Safari 3.1) and the CSS @font-face declaration +====================================================== + +I'm a big fan of typography in general. If you check out [my homepage](http://elliottcable.name) or my [contact elliottcable](http://elliottcable.name/contact.xhtml) page, and you're using Safari/WebKit or Opera/Kestrel, you'll notice the typefaces (fonts, as colloquialized) are *very* non-standard. (As of this writing, I'm using [Museo][] and [Diavlo][][^jos] heavily on both.) + +The internet has not be a friendly place for typohiles like myself, up to this point, at least. One might even say it was a frightful, mentally scarring environment for those akin to yours truly. We've been restricted to reading page after page after page on day after day after day for year after year after year abominations of markup and design enslaved by the horrible overlords we know as Lucida, Verdana, Arial, Helvetica, Geneva, Georgia, Courier, and... dare I invoke ye, thou my terrible overlord? Times New Roman. + +Wherefore art thou, my glorious Archer? And thee as well, my beautiful Garamond? The technical restrictions of that horrible monster we know as the Web Browser hath forced us all too long to use those most banal, those most common, and those most abused, out of all of the typefaces of the world. + +All hyperbole aside, I'm extremely happy to see the advent of a standard `@font-face` declaration in CSS. Internet Explorer first implemented a crutched, basic version of this way back in version 4, but nothing ever really came of it - their decision to create the proprietary .EOT[^eot] format to appease overly restrictive type foundries' worries about intellectual property (aka. the cold, hard dominatrix that we know only as Ms. Profit) truly and completely killed that initial attempt at bringing astute typography and it's advocates to the web. This new run at `@font-face` by an established, trusted, and open group (the [W3C][] itself, responsible for helping to make much of what we use as designers on the web standard and cross-system compatible) has a much better chance, in my humble opinion - and I am quite looking forward to the consequences if it succeeds. + +Now, onwards to the topic of my post as declared in the header (yes, I know, a slow start - but it's an interesting topic with an interesting history!). WebKit, the open source rendering engine behind the wonderfulness that is Safari, and how it handles the 'new' `@font-face` declaration. No, it's not really 'new', but yes, it feels like it is. + +To put it simply, and to be very blunt, it's broken. + +The [CSS spec section][spec] for `@font-face` is very specific - typefaces are to be selected based on a wide array of criteria placed in the `@font-face` declaration block itself. Various textual CSS attributes may be defined within the `@font-face` declaration, and then they will be checked when the typeface is referred to later in the CSS. For instance, if I have two `@font-face` declarations for the Diavlo family - one for regular text, and one for a heavier weighted version of the typeface - then I later utilize Diavlo in a `font-family:` attribute, it should refer to the basic Diavlo font defined in the first `@font-face`. However, if I were to do the same, but also specify a heavy `font-weight:`, then it should use the heavier version of Diavlo. To place this example in code: + + @font-face { + font-family: 'Diavlo'; + src: url(./Diavlo/Diavlo_Book.otf) format("opentype"); + } + + @font-face { + font-family: 'Diavlo'; + font-weight: 900; + src: url(./Diavlo/Diavlo_Black.otf) format("opentype"); + } + + h1, h2, h3, h4, h5, h6 { + font-family: 'Diavlo'; + font-weight: 900; + } + + div#content { + font-family: 'Diavlo'; + } + +As you can see, my headings should use the typeface defined in `Diavlo_Black.otf`, while my body content should use `Diavlo_Book.otf`. However, in WebKit, this doesn't work - it completely ignores any attribute except `font-family:` and `src:` in a `@font-face` declaration! Completely ignores them! Not only that - not *only* that - it disregards all but the last `@font-face` for a given `font-family:` attribute string! + +The implication here is that, to make `@font-face` work as it is currently implemented in WebKit (and thus, Safari 3.1), I have to declare *completely imaginary, non-existent type families* to satisfy WebKit alone. Here's the method I have used in the places I current implement `@font-face`: + + @font-face { + font-family: 'Diavlo Book'; + src: url(./Diavlo/Diavlo_Book.otf) format("opentype"); + } + + @font-face { + font-family: 'Diavlo Black'; + src: url(./Diavlo/Diavlo_Black.otf) format("opentype"); + } + + h1, h2, h3, h4, h5, h6 { + font-family: 'Diavlo Black'; + } + + div#content { + font-family: 'Diavlo Book'; + } + +Isn't it horrible? Seriously, my eyes, they bleed. There's lots of problems with this far beyond the lack of semanticity when it comes to the typeface names... let me see how many ways this breaks the purpose of `@font-face`: + + - You remove a large element our control over the display of the page. + + As soon as we begin to use `@font-face` in our page, we can no longer make any use of any other textual control attribute - `font-weight:`, `font-style:`, and `font-variant:` are no longer available to us, because they no longer correctly map to technical typeface variant/features. + + Also, many default elements are destroyed, unusable, without 'fixing' - for instance, `` would have no effect in a page styled for WebKit as above; We would have to specify something like `b {font-family: 'Diavlo Black';}` - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes? + + If we want to use Javascript to modify the display of the content, we can't simply adjust the mentioned textual control attributes - we have to know and change the entire `font-family:` array of strings. + + - You make us very wet. + + And by wet, I mean 'not DRY'. What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typeface's bastardized name. + + - You remove our user's user choice, and waste bandwidth. + + Since the names refer to families that don't, in fact, exist, the browser can't override the declaration with a user's installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser won't use that - it doesn't know to use 'Diavlo', which the user has installed, because it was told to use 'Diavlo Black', which no user in the entire world has installed on their computer. + +This whole thing is rather worrying - I've heard Opera has `@font-face` support, though I haven't had time to test this myself, so I don't know if it actually does - or, for that matter, if it does it 'correctly', or has the same problems as WebKit. But either way, WebKit is one of the first two implementations to ever attempt to support `@font-face` (Microsoft's unrelated `@font-face` declaration notwithstanding) - I really don't want to see it's early mistakes carried on to FireFox in a few years, and then Internet Explorer a few decades after that. That will leave us stuck with this broken system forever, as it has been demonstrated time and time again that if nobody else supports an old standard correctly, a newcomer to the standard will not do it correctly either. I for one would really, really, hate that. + +In summary... come on, WebKit team, this isn't like you - you're always the ones with the closest-to-standard implementation, and the cleanest code, and... hell, overall? Webkit is the most secure/fastest browser available. But this is making me lose my faith in you, guys, please get it right. You're pioneering a leap into the future when it comes to the Web - this is as important, or _more_ important, than Mosiac's allowing of images was. + +To put it succinctly - don't fuck this up, y'all. + +[Museo]: (Jos Buivenga's Museo free typeface) +[Diavlo]: (Jos Buivenga's free Diavlo typeface) +[^jos]: These are fonts by [Jos Buivenga][jos], quite the amazing person. His (free) fonts are, uniquely, released for use on the web in `@font-face` declarations - unlike the vast majority of other (even free to download) typefaces, which have ridiculously restricting licenses and terms of use statements. Props, Jos - you're a pioneer, and deserve recognition as such. +*[CSS]: Cascading Style Sheets +*[.EOT]: Embedded OpenType +[^eot]: To give Microsoft a little credit, something I rarely do... Yes, I'm aware Microsoft submitted EOT to the W3C as a proposal - the problem isn't with their attempts to make it non-proprietary, but with the basic concept of making typefaces on the web DRMed. Look what such attempts have done to the music and video industry - simply decimated it. Do we really want to see the same thing happen to our beloved medium as typography moves into the 21st century? +*[W3C]: World Wide Web Consortium +[W3C]: (World Wide Web Consortium) +[spec]: () +*[DRY]: Don't Repeat Yourself +[jos]: jos + +*** Output of inspect *** +md_el(:document,[ + md_el(:header,["WebKit (Safari 3.1) and the CSS @font-face declaration"],{:level=>1},[]), + md_par([ + "I", + md_entity("rsquo"), + "m a big fan of typography in general. If you check out ", + md_im_link(["my homepage"], "http://elliottcable.name", nil), + " or my ", + md_im_link(["contact elliottcable"], "http://elliottcable.name/contact.xhtml", nil), + " page, and you", + md_entity("rsquo"), + "re using Safari/WebKit or Opera/Kestrel, you", + md_entity("rsquo"), + "ll notice the typefaces (fonts, as colloquialized) are ", + md_em(["very"]), + " non-standard. (As of this writing, I", + md_entity("rsquo"), + "m using ", + md_link(["Museo"],"museo"), + " and ", + md_link(["Diavlo"],"diavlo"), + md_foot_ref("^jos"), + " heavily on both.)" + ]), + md_par([ + "The internet has not be a friendly place for typohiles like myself, up to this point, at least. One might even say it was a frightful, mentally scarring environment for those akin to yours truly. We", + md_entity("rsquo"), + "ve been restricted to reading page after page after page on day after day after day for year after year after year abominations of markup and design enslaved by the horrible overlords we know as Lucida, Verdana, Arial, Helvetica, Geneva, Georgia, Courier, and", + md_entity("hellip"), + " dare I invoke ye, thou my terrible overlord? Times New Roman." + ]), + md_par([ + "Wherefore art thou, my glorious Archer? And thee as well, my beautiful Garamond? The technical restrictions of that horrible monster we know as the Web Browser hath forced us all too long to use those most banal, those most common, and those most abused, out of all of the typefaces of the world." + ]), + md_par([ + "All hyperbole aside, I", + md_entity("rsquo"), + "m extremely happy to see the advent of a standard ", + md_code("@font-face"), + " declaration in CSS. Internet Explorer first implemented a crutched, basic version of this way back in version 4, but nothing ever really came of it - their decision to create the proprietary .EOT", + md_foot_ref("^eot"), + " format to appease overly restrictive type foundries", + md_entity("rsquo"), + " worries about intellectual property (aka. the cold, hard dominatrix that we know only as Ms. Profit) truly and completely killed that initial attempt at bringing astute typography and it", + md_entity("rsquo"), + "s advocates to the web. This new run at ", + md_code("@font-face"), + " by an established, trusted, and open group (the ", + md_link(["W3C"],"w3c"), + " itself, responsible for helping to make much of what we use as designers on the web standard and cross-system compatible) has a much better chance, in my humble opinion - and I am quite looking forward to the consequences if it succeeds." + ]), + md_par([ + "Now, onwards to the topic of my post as declared in the header (yes, I know, a slow start - but it", + md_entity("rsquo"), + "s an interesting topic with an interesting history!). WebKit, the open source rendering engine behind the wonderfulness that is Safari, and how it handles the ", + md_entity("lsquo"), + "new", + md_entity("rsquo"), + " ", + md_code("@font-face"), + " declaration. No, it", + md_entity("rsquo"), + "s not really ", + md_entity("lsquo"), + "new", + md_entity("rsquo"), + ", but yes, it feels like it is." + ]), + md_par([ + "To put it simply, and to be very blunt, it", + md_entity("rsquo"), + "s broken." + ]), + md_par([ + "The ", + md_link(["CSS spec section"],"spec"), + " for ", + md_code("@font-face"), + " is very specific - typefaces are to be selected based on a wide array of criteria placed in the ", + md_code("@font-face"), + " declaration block itself. Various textual CSS attributes may be defined within the ", + md_code("@font-face"), + " declaration, and then they will be checked when the typeface is referred to later in the CSS. For instance, if I have two ", + md_code("@font-face"), + " declarations for the Diavlo family - one for regular text, and one for a heavier weighted version of the typeface - then I later utilize Diavlo in a ", + md_code("font-family:"), + " attribute, it should refer to the basic Diavlo font defined in the first ", + md_code("@font-face"), + ". However, if I were to do the same, but also specify a heavy ", + md_code("font-weight:"), + ", then it should use the heavier version of Diavlo. To place this example in code:" + ]), + md_el(:code,[],{:raw_code=>"@font-face {\n font-family: 'Diavlo';\n src: url(./Diavlo/Diavlo_Book.otf) format(\"opentype\");\n}\n\n@font-face {\n font-family: 'Diavlo';\n font-weight: 900;\n src: url(./Diavlo/Diavlo_Black.otf) format(\"opentype\");\n}\n\nh1, h2, h3, h4, h5, h6 {\n font-family: 'Diavlo';\n font-weight: 900;\n}\n\ndiv#content {\n font-family: 'Diavlo';\n}"},[]), + md_par([ + "As you can see, my headings should use the typeface defined in ", + md_code("Diavlo_Black.otf"), + ", while my body content should use ", + md_code("Diavlo_Book.otf"), + ". However, in WebKit, this doesn", + md_entity("rsquo"), + "t work - it completely ignores any attribute except ", + md_code("font-family:"), + " and ", + md_code("src:"), + " in a ", + md_code("@font-face"), + " declaration! Completely ignores them! Not only that - not ", + md_em(["only"]), + " that - it disregards all but the last ", + md_code("@font-face"), + " for a given ", + md_code("font-family:"), + " attribute string!" + ]), + md_par([ + "The implication here is that, to make ", + md_code("@font-face"), + " work as it is currently implemented in WebKit (and thus, Safari 3.1), I have to declare ", + md_em(["completely imaginary, non-existent type families"]), + " to satisfy WebKit alone. Here", + md_entity("rsquo"), + "s the method I have used in the places I current implement ", + md_code("@font-face"), + ":" + ]), + md_el(:code,[],{:raw_code=>"@font-face {\n font-family: 'Diavlo Book';\n src: url(./Diavlo/Diavlo_Book.otf) format(\"opentype\");\n}\n\n@font-face {\n font-family: 'Diavlo Black';\n src: url(./Diavlo/Diavlo_Black.otf) format(\"opentype\");\n}\n\nh1, h2, h3, h4, h5, h6 {\n font-family: 'Diavlo Black';\n}\n\ndiv#content {\n font-family: 'Diavlo Book';\n}"},[]), + md_par([ + "Isn", + md_entity("rsquo"), + "t it horrible? Seriously, my eyes, they bleed. There", + md_entity("rsquo"), + "s lots of problems with this far beyond the lack of semanticity when it comes to the typeface names", + md_entity("hellip"), + " let me see how many ways this breaks the purpose of ", + md_code("@font-face"), + ":" + ]), + md_el(:ul,[ + md_el(:li,[ + md_par([ + "You remove a large element our control over the display of the page." + ]), + md_par([ + "As soon as we begin to use ", + md_code("@font-face"), + " in our page, we can no longer make any use of any other textual control attribute - ", + md_code("font-weight:"), + ", ", + md_code("font-style:"), + ", and ", + md_code("font-variant:"), + " are no longer available to us, because they no longer correctly map to technical typeface variant/features." + ]), + md_par([ + "Also, many default elements are destroyed, unusable, without ", + md_entity("lsquo"), + "fixing", + md_entity("rsquo"), + " - for instance, ", + md_code(""), + " would have no effect in a page styled for WebKit as above; We would have to specify something like ", + md_code("b {font-family: 'Diavlo Black';}"), + " - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes?" + ]), + md_par([ + "If we want to use Javascript to modify the display of the content, we can", + md_entity("rsquo"), + "t simply adjust the mentioned textual control attributes - we have to know and change the entire ", + md_code("font-family:"), + " array of strings." + ]) + ],{:want_my_paragraph=>true},[]), + md_el(:li,[ + md_par(["You make us very wet."]), + md_par([ + "And by wet, I mean ", + md_entity("lsquo"), + "not DRY", + md_entity("rsquo"), + ". What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typeface", + md_entity("rsquo"), + "s bastardized name." + ]) + ],{:want_my_paragraph=>true},[]), + md_el(:li,[ + md_par([ + "You remove our user", + md_entity("rsquo"), + "s user choice, and waste bandwidth." + ]), + md_par([ + "Since the names refer to families that don", + md_entity("rsquo"), + "t, in fact, exist, the browser can", + md_entity("rsquo"), + "t override the declaration with a user", + md_entity("rsquo"), + "s installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser won", + md_entity("rsquo"), + "t use that - it doesn", + md_entity("rsquo"), + "t know to use ", + md_entity("lsquo"), + "Diavlo", + md_entity("rsquo"), + ", which the user has installed, because it was told to use ", + md_entity("lsquo"), + "Diavlo Black", + md_entity("rsquo"), + ", which no user in the entire world has installed on their computer." + ]) + ],{:want_my_paragraph=>true},[]) + ],{},[]), + md_par([ + "This whole thing is rather worrying - I", + md_entity("rsquo"), + "ve heard Opera has ", + md_code("@font-face"), + " support, though I haven", + md_entity("rsquo"), + "t had time to test this myself, so I don", + md_entity("rsquo"), + "t know if it actually does - or, for that matter, if it does it ", + md_entity("lsquo"), + "correctly", + md_entity("rsquo"), + ", or has the same problems as WebKit. But either way, WebKit is one of the first two implementations to ever attempt to support ", + md_code("@font-face"), + " (Microsoft", + md_entity("rsquo"), + "s unrelated ", + md_code("@font-face"), + " declaration notwithstanding) - I really don", + md_entity("rsquo"), + "t want to see it", + md_entity("rsquo"), + "s early mistakes carried on to FireFox in a few years, and then Internet Explorer a few decades after that. That will leave us stuck with this broken system forever, as it has been demonstrated time and time again that if nobody else supports an old standard correctly, a newcomer to the standard will not do it correctly either. I for one would really, really, hate that." + ]), + md_par([ + "In summary", + md_entity("hellip"), + " come on, WebKit team, this isn", + md_entity("rsquo"), + "t like you - you", + md_entity("rsquo"), + "re always the ones with the closest-to-standard implementation, and the cleanest code, and", + md_entity("hellip"), + " hell, overall? Webkit is the most secure/fastest browser available. But this is making me lose my faith in you, guys, please get it right. You", + md_entity("rsquo"), + "re pioneering a leap into the future when it comes to the Web - this is as important, or ", + md_em(["more"]), + " important, than Mosiac", + md_entity("rsquo"), + "s allowing of images was." + ]), + md_par([ + "To put it succinctly - don", + md_entity("rsquo"), + "t fuck this up, y", + md_entity("rsquo"), + "all." + ]), + md_ref_def("museo", "http://www.josbuivenga.demon.nl/museo.html>", {:title=>"Jos Buivenga"}), + md_ref_def("diavlo", "http://www.josbuivenga.demon.nl/diavlo.html>", {:title=>"Jos Buivenga"}), + md_par([ + md_em([md_link(["CSS"],"css"), ": Cascading Style Sheets"]), + md_link([".EOT"],"eot"), + ": Embedded OpenType ", + md_foot_ref("^eot"), + ": To give Microsoft a little credit, something I rarely do", + md_entity("hellip"), + " Yes, I", + md_entity("rsquo"), + "m aware Microsoft submitted EOT to the W3C as a proposal - the problem isn", + md_entity("rsquo"), + "t with their attempts to make it non-proprietary, but with the basic concept of making typefaces on the web DRMed. Look what such attempts have done to the music and video industry - simply decimated it. Do we really want to see the same thing happen to our beloved medium as typography moves into the 21st century? ", + md_em([md_link(["W3C"],"w3c"), ": World Wide Web Consortium"]) + ]), + md_ref_def("w3c", "http://w3c.org>", {:title=>"World Wide Web Consortium"}), + md_ref_def("spec", "http://?>", {:title=>") *[DRY]: Don"}) +],{},[]) +*** Output of to_html *** +

WebKit (Safari 3.1) and the CSS @font-face declaration

+ +

I’m a big fan of typography in general. If you check out my homepage or my contact elliottcable page, and you’re using Safari/WebKit or Opera/Kestrel, you’ll notice the typefaces (fonts, as colloquialized) are very non-standard. (As of this writing, I’m using Museo and Diavlo1 heavily on both.)

+ +

The internet has not be a friendly place for typohiles like myself, up to this point, at least. One might even say it was a frightful, mentally scarring environment for those akin to yours truly. We’ve been restricted to reading page after page after page on day after day after day for year after year after year abominations of markup and design enslaved by the horrible overlords we know as Lucida, Verdana, Arial, Helvetica, Geneva, Georgia, Courier, and… dare I invoke ye, thou my terrible overlord? Times New Roman.

+ +

Wherefore art thou, my glorious Archer? And thee as well, my beautiful Garamond? The technical restrictions of that horrible monster we know as the Web Browser hath forced us all too long to use those most banal, those most common, and those most abused, out of all of the typefaces of the world.

+ +

All hyperbole aside, I’m extremely happy to see the advent of a standard @font-face declaration in CSS. Internet Explorer first implemented a crutched, basic version of this way back in version 4, but nothing ever really came of it - their decision to create the proprietary .EOT2 format to appease overly restrictive type foundries’ worries about intellectual property (aka. the cold, hard dominatrix that we know only as Ms. Profit) truly and completely killed that initial attempt at bringing astute typography and it’s advocates to the web. This new run at @font-face by an established, trusted, and open group (the W3C itself, responsible for helping to make much of what we use as designers on the web standard and cross-system compatible) has a much better chance, in my humble opinion - and I am quite looking forward to the consequences if it succeeds.

+ +

Now, onwards to the topic of my post as declared in the header (yes, I know, a slow start - but it’s an interesting topic with an interesting history!). WebKit, the open source rendering engine behind the wonderfulness that is Safari, and how it handles the ‘new’ @font-face declaration. No, it’s not really ‘new’, but yes, it feels like it is.

+ +

To put it simply, and to be very blunt, it’s broken.

+ +

The CSS spec section for @font-face is very specific - typefaces are to be selected based on a wide array of criteria placed in the @font-face declaration block itself. Various textual CSS attributes may be defined within the @font-face declaration, and then they will be checked when the typeface is referred to later in the CSS. For instance, if I have two @font-face declarations for the Diavlo family - one for regular text, and one for a heavier weighted version of the typeface - then I later utilize Diavlo in a font-family: attribute, it should refer to the basic Diavlo font defined in the first @font-face. However, if I were to do the same, but also specify a heavy font-weight:, then it should use the heavier version of Diavlo. To place this example in code:

+ +
@font-face {
+  font-family: 'Diavlo';
+  src: url(./Diavlo/Diavlo_Book.otf) format("opentype");
+}
+
+@font-face {
+  font-family: 'Diavlo';
+  font-weight: 900;
+  src: url(./Diavlo/Diavlo_Black.otf) format("opentype");
+}
+
+h1, h2, h3, h4, h5, h6 {
+  font-family: 'Diavlo';
+  font-weight: 900;
+}
+
+div#content {
+  font-family: 'Diavlo';
+}
+ +

As you can see, my headings should use the typeface defined in Diavlo_Black.otf, while my body content should use Diavlo_Book.otf. However, in WebKit, this doesn’t work - it completely ignores any attribute except font-family: and src: in a @font-face declaration! Completely ignores them! Not only that - not only that - it disregards all but the last @font-face for a given font-family: attribute string!

+ +

The implication here is that, to make @font-face work as it is currently implemented in WebKit (and thus, Safari 3.1), I have to declare completely imaginary, non-existent type families to satisfy WebKit alone. Here’s the method I have used in the places I current implement @font-face:

+ +
@font-face {
+  font-family: 'Diavlo Book';
+  src: url(./Diavlo/Diavlo_Book.otf) format("opentype");
+}
+
+@font-face {
+  font-family: 'Diavlo Black';
+  src: url(./Diavlo/Diavlo_Black.otf) format("opentype");
+}
+
+h1, h2, h3, h4, h5, h6 {
+  font-family: 'Diavlo Black';
+}
+
+div#content {
+  font-family: 'Diavlo Book';
+}
+ +

Isn’t it horrible? Seriously, my eyes, they bleed. There’s lots of problems with this far beyond the lack of semanticity when it comes to the typeface names… let me see how many ways this breaks the purpose of @font-face:

+ +
    +
  • +

    You remove a large element our control over the display of the page.

    + +

    As soon as we begin to use @font-face in our page, we can no longer make any use of any other textual control attribute - font-weight:, font-style:, and font-variant: are no longer available to us, because they no longer correctly map to technical typeface variant/features.

    + +

    Also, many default elements are destroyed, unusable, without ‘fixing’ - for instance, <b> would have no effect in a page styled for WebKit as above; We would have to specify something like b {font-family: 'Diavlo Black';} - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes?

    + +

    If we want to use Javascript to modify the display of the content, we can’t simply adjust the mentioned textual control attributes - we have to know and change the entire font-family: array of strings.

    +
    • + +
  • +

    You make us very wet.

    + +

    And by wet, I mean ‘not DRY’. What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typeface’s bastardized name.

    +
    • + +
  • +

    You remove our user’s user choice, and waste bandwidth.

    + +

    Since the names refer to families that don’t, in fact, exist, the browser can’t override the declaration with a user’s installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser won’t use that - it doesn’t know to use ‘Diavlo’, which the user has installed, because it was told to use ‘Diavlo Black’, which no user in the entire world has installed on their computer.

    +
    • +
+ +

This whole thing is rather worrying - I’ve heard Opera has @font-face support, though I haven’t had time to test this myself, so I don’t know if it actually does - or, for that matter, if it does it ‘correctly’, or has the same problems as WebKit. But either way, WebKit is one of the first two implementations to ever attempt to support @font-face (Microsoft’s unrelated @font-face declaration notwithstanding) - I really don’t want to see it’s early mistakes carried on to FireFox in a few years, and then Internet Explorer a few decades after that. That will leave us stuck with this broken system forever, as it has been demonstrated time and time again that if nobody else supports an old standard correctly, a newcomer to the standard will not do it correctly either. I for one would really, really, hate that.

+ +

In summary… come on, WebKit team, this isn’t like you - you’re always the ones with the closest-to-standard implementation, and the cleanest code, and… hell, overall? Webkit is the most secure/fastest browser available. But this is making me lose my faith in you, guys, please get it right. You’re pioneering a leap into the future when it comes to the Web - this is as important, or more important, than Mosiac’s allowing of images was.

+ +

To put it succinctly - don’t fuck this up, y’all.

+ +

CSS: Cascading Style Sheets.EOT: Embedded OpenType 3: To give Microsoft a little credit, something I rarely do… Yes, I’m aware Microsoft submitted EOT to the W3C as a proposal - the problem isn’t with their attempts to make it non-proprietary, but with the basic concept of making typefaces on the web DRMed. Look what such attempts have done to the music and video industry - simply decimated it. Do we really want to see the same thing happen to our beloved medium as typography moves into the 21st century? W3C: World Wide Web Consortium

+
    +*** Output of to_latex *** +# +./lib/maruku/output/to_latex.rb:466:in `to_latex_footnote_reference' +./lib/maruku/output/to_latex.rb:538:in `send' +./lib/maruku/output/to_latex.rb:538:in `array_to_latex' +./lib/maruku/output/to_latex.rb:529:in `each' +./lib/maruku/output/to_latex.rb:529:in `array_to_latex' +./lib/maruku/output/to_latex.rb:524:in `children_to_latex' +./lib/maruku/output/to_latex.rb:158:in `to_latex_paragraph' +./lib/maruku/output/to_latex.rb:538:in `send' +./lib/maruku/output/to_latex.rb:538:in `array_to_latex' +./lib/maruku/output/to_latex.rb:529:in `each' +./lib/maruku/output/to_latex.rb:529:in `array_to_latex' +./lib/maruku/output/to_latex.rb:524:in `children_to_latex' +./lib/maruku/output/to_latex.rb:42:in `to_latex' +bin/marutest:93:in `send' +bin/marutest:93:in `run_test' +bin/marutest:88:in `each' +bin/marutest:88:in `run_test' +bin/marutest:262:in `marutest' +bin/marutest:259:in `each' +bin/marutest:259:in `marutest' +bin/marutest:334 +*** Output of to_md *** +WebKit (Safari 3.1) and the CSS @font-face declarationI m a big fan of typography in general. +If you check out my homepageor my +contact elliottcablepage, and you re +using Safari/WebKit or Opera/Kestrel, +you ll notice the typefaces (fonts, as +colloquialized) are verynon-standard. +(As of this writing, I m using Museoand +Diavloheavily on both.) + +The internet has not be a friendly +place for typohiles like myself, up to +this point, at least. One might even +say it was a frightful, mentally +scarring environment for those akin to +yours truly. We ve been restricted to +reading page after page after page on +day after day after day for year after +year after year abominations of markup +and design enslaved by the horrible +overlords we know as Lucida, Verdana, +Arial, Helvetica, Geneva, Georgia, +Courier, and dare I invoke ye, thou my +terrible overlord? Times New Roman. + +Wherefore art thou, my glorious Archer? +And thee as well, my beautiful +Garamond? The technical restrictions of +that horrible monster we know as the +Web Browser hath forced us all too long +to use those most banal, those most +common, and those most abused, out of +all of the typefaces of the world. + +All hyperbole aside, I m extremely +happy to see the advent of a standard +declaration in CSS. Internet Explorer +first implemented a crutched, basic +version of this way back in version 4, +but nothing ever really came of it - +their decision to create the +proprietary .EOT format to appease +overly restrictive type foundries +worries about intellectual property +(aka. the cold, hard dominatrix that we +know only as Ms. Profit) truly and +completely killed that initial attempt +at bringing astute typography and it s +advocates to the web. This new run at +by an established, trusted, and open +group (the W3Citself, responsible for +helping to make much of what we use as +designers on the web standard and +cross-system compatible) has a much +better chance, in my humble opinion - +and I am quite looking forward to the +consequences if it succeeds. + +Now, onwards to the topic of my post as +declared in the header (yes, I know, a +slow start - but it s an interesting +topic with an interesting history!). +WebKit, the open source rendering +engine behind the wonderfulness that is +Safari, and how it handles the new +declaration. No, it s not really new , +but yes, it feels like it is. + +To put it simply, and to be very blunt, +it s broken. + +The CSS spec sectionfor is very +specific - typefaces are to be selected +based on a wide array of criteria +placed in the declaration block itself. +Various textual CSS attributes may be +defined within the declaration, and +then they will be checked when the +typeface is referred to later in the +CSS. For instance, if I have two +declarations for the Diavlo family - +one for regular text, and one for a +heavier weighted version of the +typeface - then I later utilize Diavlo +in a attribute, it should refer to the +basic Diavlo font defined in the first +. However, if I were to do the same, +but also specify a heavy , then it +should use the heavier version of +Diavlo. To place this example in code: + +As you can see, my headings should use +the typeface defined in , while my body +content should use . However, in +WebKit, this doesn t work - it +completely ignores any attribute except +and in a declaration! Completely +ignores them! Not only that - not only +that - it disregards all but the last +for a given attribute string! + +The implication here is that, to make +work as it is currently implemented in +WebKit (and thus, Safari 3.1), I have +to declare +completely imaginary, non-existent type families +to satisfy WebKit alone. Here s the +method I have used in the places I +current implement : + +Isn t it horrible? Seriously, my eyes, +they bleed. There s lots of problems +with this far beyond the lack of +semanticity when it comes to the +typeface names let me see how many ways +this breaks the purpose of : + +-You remove a large element our control over the display of the page. +As soon as we begin to use in our page, we can no longer make any use of any other textual control attribute - , , and are no longer available to us, because they no longer correctly map to technical typeface variant/features. +Also, many default elements are destroyed, unusable, without fixing - for instance, would have no effect in a page styled for WebKit as above; We would have to specify something like - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes? +If we want to use Javascript to modify the display of the content, we cant simply adjust the mentioned textual control attributes - we have to know and change the entire array of strings. +-ou make us very wet. +And by wet, I mean not DRY. What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typefaces bastardized name. +-You remove our users user choice, and waste bandwidth. +Since the names refer to families that dont, in fact, exist, the browser cant override the declaration with a users installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser wont use that - it doesnt know to use Diavlo, which the user has installed, because it was told to use Diavlo Black, which no user in the entire world has installed on their computer. + +This whole thing is rather worrying - I +ve heard Opera has support, though I +haven t had time to test this myself, +so I don t know if it actually does - +or, for that matter, if it does it +correctly , or has the same problems as +WebKit. But either way, WebKit is one +of the first two implementations to +ever attempt to support (Microsoft s +unrelated declaration notwithstanding) +- I really don t want to see it s early +mistakes carried on to FireFox in a few +years, and then Internet Explorer a few +decades after that. That will leave us +stuck with this broken system forever, +as it has been demonstrated time and +time again that if nobody else supports +an old standard correctly, a newcomer +to the standard will not do it +correctly either. I for one would +really, really, hate that. + +In summary come on, WebKit team, this +isn t like you - you re always the ones +with the closest-to-standard +implementation, and the cleanest code, +and hell, overall? Webkit is the most +secure/fastest browser available. But +this is making me lose my faith in you, +guys, please get it right. You re +pioneering a leap into the future when +it comes to the Web - this is as +important, or moreimportant, than +Mosiac s allowing of images was. + +To put it succinctly - don t fuck this +up, y all. + +CSS: Cascading Style Sheets.EOT: +Embedded OpenType : To give Microsoft a +little credit, something I rarely do +Yes, I m aware Microsoft submitted EOT +to the W3C as a proposal - the problem +isn t with their attempts to make it +non-proprietary, but with the basic +concept of making typefaces on the web +DRMed. Look what such attempts have +done to the music and video industry - +simply decimated it. Do we really want +to see the same thing happen to our +beloved medium as typography moves into +the 21st century? +W3C: World Wide Web Consortium +*** Output of to_s *** +WebKit (Safari 3.1) and the CSS @font-face declarationIm a big fan of typography in general. If you check out my homepage or my contact elliottcable page, and youre using Safari/WebKit or Opera/Kestrel, youll notice the typefaces (fonts, as colloquialized) are very non-standard. (As of this writing, Im using Museo and Diavlo heavily on both.)The internet has not be a friendly place for typohiles like myself, up to this point, at least. One might even say it was a frightful, mentally scarring environment for those akin to yours truly. Weve been restricted to reading page after page after page on day after day after day for year after year after year abominations of markup and design enslaved by the horrible overlords we know as Lucida, Verdana, Arial, Helvetica, Geneva, Georgia, Courier, and dare I invoke ye, thou my terrible overlord? Times New Roman.Wherefore art thou, my glorious Archer? And thee as well, my beautiful Garamond? The technical restrictions of that horrible monster we know as the Web Browser hath forced us all too long to use those most banal, those most common, and those most abused, out of all of the typefaces of the world.All hyperbole aside, Im extremely happy to see the advent of a standard declaration in CSS. Internet Explorer first implemented a crutched, basic version of this way back in version 4, but nothing ever really came of it - their decision to create the proprietary .EOT format to appease overly restrictive type foundries worries about intellectual property (aka. the cold, hard dominatrix that we know only as Ms. Profit) truly and completely killed that initial attempt at bringing astute typography and its advocates to the web. This new run at by an established, trusted, and open group (the W3C itself, responsible for helping to make much of what we use as designers on the web standard and cross-system compatible) has a much better chance, in my humble opinion - and I am quite looking forward to the consequences if it succeeds.Now, onwards to the topic of my post as declared in the header (yes, I know, a slow start - but its an interesting topic with an interesting history!). WebKit, the open source rendering engine behind the wonderfulness that is Safari, and how it handles the new declaration. No, its not really new, but yes, it feels like it is.To put it simply, and to be very blunt, its broken.The CSS spec section for is very specific - typefaces are to be selected based on a wide array of criteria placed in the declaration block itself. Various textual CSS attributes may be defined within the declaration, and then they will be checked when the typeface is referred to later in the CSS. For instance, if I have two declarations for the Diavlo family - one for regular text, and one for a heavier weighted version of the typeface - then I later utilize Diavlo in a attribute, it should refer to the basic Diavlo font defined in the first . However, if I were to do the same, but also specify a heavy , then it should use the heavier version of Diavlo. To place this example in code:As you can see, my headings should use the typeface defined in , while my body content should use . However, in WebKit, this doesnt work - it completely ignores any attribute except and in a declaration! Completely ignores them! Not only that - not only that - it disregards all but the last for a given attribute string!The implication here is that, to make work as it is currently implemented in WebKit (and thus, Safari 3.1), I have to declare completely imaginary, non-existent type families to satisfy WebKit alone. Heres the method I have used in the places I current implement :Isnt it horrible? Seriously, my eyes, they bleed. Theres lots of problems with this far beyond the lack of semanticity when it comes to the typeface names let me see how many ways this breaks the purpose of :You remove a large element our control over the display of the page.As soon as we begin to use in our page, we can no longer make any use of any other textual control attribute - , , and are no longer available to us, because they no longer correctly map to technical typeface variant/features.Also, many default elements are destroyed, unusable, without fixing - for instance, would have no effect in a page styled for WebKit as above; We would have to specify something like - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes?If we want to use Javascript to modify the display of the content, we cant simply adjust the mentioned textual control attributes - we have to know and change the entire array of strings.You make us very wet.And by wet, I mean not DRY. What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typefaces bastardized name.You remove our users user choice, and waste bandwidth.Since the names refer to families that dont, in fact, exist, the browser cant override the declaration with a users installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser wont use that - it doesnt know to use Diavlo, which the user has installed, because it was told to use Diavlo Black, which no user in the entire world has installed on their computer.This whole thing is rather worrying - Ive heard Opera has support, though I havent had time to test this myself, so I dont know if it actually does - or, for that matter, if it does it correctly, or has the same problems as WebKit. But either way, WebKit is one of the first two implementations to ever attempt to support (Microsofts unrelated declaration notwithstanding) - I really dont want to see its early mistakes carried on to FireFox in a few years, and then Internet Explorer a few decades after that. That will leave us stuck with this broken system forever, as it has been demonstrated time and time again that if nobody else supports an old standard correctly, a newcomer to the standard will not do it correctly either. I for one would really, really, hate that.In summary come on, WebKit team, this isnt like you - youre always the ones with the closest-to-standard implementation, and the cleanest code, and hell, overall? Webkit is the most secure/fastest browser available. But this is making me lose my faith in you, guys, please get it right. Youre pioneering a leap into the future when it comes to the Web - this is as important, or more important, than Mosiacs allowing of images was.To put it succinctly - dont fuck this up, yall.CSS: Cascading Style Sheets.EOT: Embedded OpenType : To give Microsoft a little credit, something I rarely do Yes, Im aware Microsoft submitted EOT to the W3C as a proposal - the problem isnt with their attempts to make it non-proprietary, but with the basic concept of making typefaces on the web DRMed. Look what such attempts have done to the music and video industry - simply decimated it. Do we really want to see the same thing happen to our beloved medium as typography moves into the 21st century? W3C: World Wide Web Consortium +*** EOF *** + + + + +Failed tests: [:inspect, :to_html, :to_latex, :to_md, :to_s] + +*** Output of inspect *** +-----| WARNING | ----- +md_el(:document,[ + md_el(:header,[ + "WebKit (Safari 3.1) and the ", + md_el(:abbr,["CSS"],{:title=>"Cascading Style Sheets"},[]), + " @font-face declaration" + ],{:level=>1},[]), + md_par([ + "I", + md_entity("rsquo"), + "m a big fan of typography in general. If you check out ", + md_im_link(["my homepage"], "http://elliottcable.name", nil), + " or my ", + md_im_link(["contact elliottcable"], "http://elliottcable.name/contact.xhtml", nil), + " page, and you", + md_entity("rsquo"), + "re using Safari/WebKit or Opera/Kestrel, you", + md_entity("rsquo"), + "ll notice the typefaces (fonts, as colloquialized) are ", + md_em(["very"]), + " non-standard. (As of this writing, I", + md_entity("rsquo"), + "m using ", + md_link(["Museo"],"museo"), + " and ", + md_link(["Diavlo"],"diavlo"), + md_foot_ref("^jos"), + " heavily on both.)" + ]), + md_par([ + "The internet has not be a friendly place for typohiles like myself, up to this point, at least. One might even say it was a frightful, mentally scarring environment for those akin to yours truly. We", + md_entity("rsquo"), + "ve been restricted to reading page after page after page on day after day after day for year after year after year abominations of markup and design enslaved by the horrible overlords we know as Lucida, Verdana, Arial, Helvetica, Geneva, Georgia, Courier, and", + md_entity("hellip"), + " dare I invoke ye, thou my terrible overlord? Times New Roman." + ]), + md_par([ + "Wherefore art thou, my glorious Archer? And thee as well, my beautiful Garamond? The technical restrictions of that horrible monster we know as the Web Browser hath forced us all too long to use those most banal, those most common, and those most abused, out of all of the typefaces of the world." + ]), + md_par([ + "All hyperbole aside, I", + md_entity("rsquo"), + "m extremely happy to see the advent of a standard ", + md_code("@font-face"), + " declaration in ", + md_el(:abbr,["CSS"],{:title=>"Cascading Style Sheets"},[]), + ". Internet Explorer first implemented a crutched, basic version of this way back in version 4, but nothing ever really came of it - their decision to create the proprietary ", + md_el(:abbr,[".EOT"],{:title=>"Embedded OpenType"},[]), + md_foot_ref("^eot"), + " format to appease overly restrictive type foundries", + md_entity("rsquo"), + " worries about intellectual property (aka. the cold, hard dominatrix that we know only as Ms. Profit) truly and completely killed that initial attempt at bringing astute typography and it", + md_entity("rsquo"), + "s advocates to the web. This new run at ", + md_code("@font-face"), + " by an established, trusted, and open group (the ", + md_link([ + "", + md_el(:abbr,["W3C"],{:title=>"World Wide Web Consortium"},[]), + "" + ],"w3c"), + " itself, responsible for helping to make much of what we use as designers on the web standard and cross-system compatible) has a much better chance, in my humble opinion - and I am quite looking forward to the consequences if it succeeds." + ]), + md_par([ + "Now, onwards to the topic of my post as declared in the header (yes, I know, a slow start - but it", + md_entity("rsquo"), + "s an interesting topic with an interesting history!). WebKit, the open source rendering engine behind the wonderfulness that is Safari, and how it handles the ", + md_entity("lsquo"), + "new", + md_entity("rsquo"), + " ", + md_code("@font-face"), + " declaration. No, it", + md_entity("rsquo"), + "s not really ", + md_entity("lsquo"), + "new", + md_entity("rsquo"), + ", but yes, it feels like it is." + ]), + md_par([ + "To put it simply, and to be very blunt, it", + md_entity("rsquo"), + "s broken." + ]), + md_par([ + "The ", + md_link([ + md_el(:abbr,["CSS"],{:title=>"Cascading Style Sheets"},[]), + " spec section" + ],"spec"), + " for ", + md_code("@font-face"), + " is very specific - typefaces are to be selected based on a wide array of criteria placed in the ", + md_code("@font-face"), + " declaration block itself. Various textual ", + md_el(:abbr,["CSS"],{:title=>"Cascading Style Sheets"},[]), + " attributes may be defined within the ", + md_code("@font-face"), + " declaration, and then they will be checked when the typeface is referred to later in the ", + md_el(:abbr,["CSS"],{:title=>"Cascading Style Sheets"},[]), + ". For instance, if I have two ", + md_code("@font-face"), + " declarations for the Diavlo family - one for regular text, and one for a heavier weighted version of the typeface - then I later utilize Diavlo in a ", + md_code("font-family:"), + " attribute, it should refer to the basic Diavlo font defined in the first ", + md_code("@font-face"), + ". However, if I were to do the same, but also specify a heavy ", + md_code("font-weight:"), + ", then it should use the heavier version of Diavlo. To place this example in code:" + ]), + md_el(:code,[],{:raw_code=>"@font-face {\n font-family: 'Diavlo';\n src: url(./Diavlo/Diavlo_Book.otf) format(\"opentype\");\n}\n\n@font-face {\n font-family: 'Diavlo';\n font-weight: 900;\n src: url(./Diavlo/Diavlo_Black.otf) format(\"opentype\");\n}\n\nh1, h2, h3, h4, h5, h6 {\n font-family: 'Diavlo';\n font-weight: 900;\n}\n\ndiv#content {\n font-family: 'Diavlo';\n}"},[]), + md_par([ + "As you can see, my headings should use the typeface defined in ", + md_code("Diavlo_Black.otf"), + ", while my body content should use ", + md_code("Diavlo_Book.otf"), + ". However, in WebKit, this doesn", + md_entity("rsquo"), + "t work - it completely ignores any attribute except ", + md_code("font-family:"), + " and ", + md_code("src:"), + " in a ", + md_code("@font-face"), + " declaration! Completely ignores them! Not only that - not ", + md_em(["only"]), + " that - it disregards all but the last ", + md_code("@font-face"), + " for a given ", + md_code("font-family:"), + " attribute string!" + ]), + md_par([ + "The implication here is that, to make ", + md_code("@font-face"), + " work as it is currently implemented in WebKit (and thus, Safari 3.1), I have to declare ", + md_em(["completely imaginary, non-existent type families"]), + " to satisfy WebKit alone. Here", + md_entity("rsquo"), + "s the method I have used in the places I current implement ", + md_code("@font-face"), + ":" + ]), + md_el(:code,[],{:raw_code=>"@font-face {\n font-family: 'Diavlo Book';\n src: url(./Diavlo/Diavlo_Book.otf) format(\"opentype\");\n}\n\n@font-face {\n font-family: 'Diavlo Black';\n src: url(./Diavlo/Diavlo_Black.otf) format(\"opentype\");\n}\n\nh1, h2, h3, h4, h5, h6 {\n font-family: 'Diavlo Black';\n}\n\ndiv#content {\n font-family: 'Diavlo Book';\n}"},[]), + md_par([ + "Isn", + md_entity("rsquo"), + "t it horrible? Seriously, my eyes, they bleed. There", + md_entity("rsquo"), + "s lots of problems with this far beyond the lack of semanticity when it comes to the typeface names", + md_entity("hellip"), + " let me see how many ways this breaks the purpose of ", + md_code("@font-face"), + ":" + ]), + md_el(:ul,[ + md_el(:li,[ + md_par([ + "You remove a large element our control over the display of the page." + ]), + md_par([ + "As soon as we begin to use ", + md_code("@font-face"), + " in our page, we can no longer make any use of any other textual control attribute - ", + md_code("font-weight:"), + ", ", + md_code("font-style:"), + ", and ", + md_code("font-variant:"), + " are no longer available to us, because they no longer correctly map to technical typeface variant/features." + ]), + md_par([ + "Also, many default elements are destroyed, unusable, without ", + md_entity("lsquo"), + "fixing", + md_entity("rsquo"), + " - for instance, ", + md_code(""), + " would have no effect in a page styled for WebKit as above; We would have to specify something like ", + md_code("b {font-family: 'Diavlo Black';}"), + " - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes?" + ]), + md_par([ + "If we want to use Javascript to modify the display of the content, we can", + md_entity("rsquo"), + "t simply adjust the mentioned textual control attributes - we have to know and change the entire ", + md_code("font-family:"), + " array of strings." + ]) + ],{:want_my_paragraph=>true},[]), + md_el(:li,[ + md_par(["You make us very wet."]), + md_par([ + "And by wet, I mean ", + md_entity("lsquo"), + "not ", + md_el(:abbr,["DRY"],{:title=>"Don't Repeat Yourself"},[]), + md_entity("rsquo"), + ". What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our ", + md_el(:abbr,["CSS"],{:title=>"Cascading Style Sheets"},[]), + ", all of our Javascript, and make sure we update every occurrence of the typeface", + md_entity("rsquo"), + "s bastardized name." + ]) + ],{:want_my_paragraph=>true},[]), + md_el(:li,[ + md_par([ + "You remove our user", + md_entity("rsquo"), + "s user choice, and waste bandwidth." + ]), + md_par([ + "Since the names refer to families that don", + md_entity("rsquo"), + "t, in fact, exist, the browser can", + md_entity("rsquo"), + "t override the declaration with a user", + md_entity("rsquo"), + "s installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser won", + md_entity("rsquo"), + "t use that - it doesn", + md_entity("rsquo"), + "t know to use ", + md_entity("lsquo"), + "Diavlo", + md_entity("rsquo"), + ", which the user has installed, because it was told to use ", + md_entity("lsquo"), + "Diavlo Black", + md_entity("rsquo"), + ", which no user in the entire world has installed on their computer." + ]) + ],{:want_my_paragraph=>true},[]) + ],{},[]), + md_par([ + "This whole thing is rather worrying - I", + md_entity("rsquo"), + "ve heard Opera has ", + md_code("@font-face"), + " support, though I haven", + md_entity("rsquo"), + "t had time to test this myself, so I don", + md_entity("rsquo"), + "t know if it actually does - or, for that matter, if it does it ", + md_entity("lsquo"), + "correctly", + md_entity("rsquo"), + ", or has the same problems as WebKit. But either way, WebKit is one of the first two implementations to ever attempt to support ", + md_code("@font-face"), + " (Microsoft", + md_entity("rsquo"), + "s unrelated ", + md_code("@font-face"), + " declaration notwithstanding) - I really don", + md_entity("rsquo"), + "t want to see it", + md_entity("rsquo"), + "s early mistakes carried on to FireFox in a few years, and then Internet Explorer a few decades after that. That will leave us stuck with this broken system forever, as it has been demonstrated time and time again that if nobody else supports an old standard correctly, a newcomer to the standard will not do it correctly either. I for one would really, really, hate that." + ]), + md_par([ + "In summary", + md_entity("hellip"), + " come on, WebKit team, this isn", + md_entity("rsquo"), + "t like you - you", + md_entity("rsquo"), + "re always the ones with the closest-to-standard implementation, and the cleanest code, and", + md_entity("hellip"), + " hell, overall? Webkit is the most secure/fastest browser available. But this is making me lose my faith in you, guys, please get it right. You", + md_entity("rsquo"), + "re pioneering a leap into the future when it comes to the Web - this is as important, or ", + md_em(["more"]), + " important, than Mosiac", + md_entity("rsquo"), + "s allowing of images was." + ]), + md_par([ + "To put it succinctly - don", + md_entity("rsquo"), + "t fuck this up, y", + md_entity("rsquo"), + "all." + ]), + md_ref_def("museo", "http://www.josbuivenga.demon.nl/museo.html", {:title=>"Jos Buivenga"}), + md_ref_def("diavlo", "http://www.josbuivenga.demon.nl/diavlo.html", {:title=>"Jos Buivenga"}), + md_el(:footnote,[ + md_par([ + "These are fonts by ", + md_link(["Jos Buivenga"],"jos"), + ", quite the amazing person. His (free) fonts are, uniquely, released for use on the web in ", + md_code("@font-face"), + " declarations - unlike the vast majority of other (even free to download) typefaces, which have ridiculously restricting licenses and terms of use statements. Props, Jos - you", + md_entity("rsquo"), + "re a pioneer, and deserve recognition as such." + ]) + ],{:footnote_id=>"^jos"},[]), + md_el(:abbr_def,[],{:abbr=>"CSS",:text=>"Cascading Style Sheets"},[]), + md_el(:abbr_def,[],{:abbr=>".EOT",:text=>"Embedded OpenType"},[]), + md_el(:footnote,[ + md_par([ + "To give Microsoft a little credit, something I rarely do", + md_entity("hellip"), + " Yes, I", + md_entity("rsquo"), + "m aware Microsoft submitted EOT to the ", + md_el(:abbr,["W3C"],{:title=>"World Wide Web Consortium"},[]), + " as a proposal - the problem isn", + md_entity("rsquo"), + "t with their attempts to make it non-proprietary, but with the basic concept of making typefaces on the web DRMed. Look what such attempts have done to the music and video industry - simply decimated it. Do we really want to see the same thing happen to our beloved medium as typography moves into the 21st century?" + ]) + ],{:footnote_id=>"^eot"},[]), + md_el(:abbr_def,[],{:abbr=>"W3C",:text=>"World Wide Web Consortium"},[]), + md_ref_def("w3c", "http://w3c.org", {:title=>"World Wide Web Consortium"}), + md_ref_def("spec", "http://?", {:title=>nil}), + md_el(:abbr_def,[],{:abbr=>"DRY",:text=>"Don't Repeat Yourself"},[]), + md_ref_def("jos", "jos", {:title=>nil}) +],{},[]) +*** Output of to_html *** +-----| WARNING | ----- +

    WebKit (Safari 3.1) and the CSS @font-face declaration

    + +

    I’m a big fan of typography in general. If you check out my homepage or my contact elliottcable page, and you’re using Safari/WebKit or Opera/Kestrel, you’ll notice the typefaces (fonts, as colloquialized) are very non-standard. (As of this writing, I’m using Museo and Diavlo1 heavily on both.)

    + +

    The internet has not be a friendly place for typohiles like myself, up to this point, at least. One might even say it was a frightful, mentally scarring environment for those akin to yours truly. We’ve been restricted to reading page after page after page on day after day after day for year after year after year abominations of markup and design enslaved by the horrible overlords we know as Lucida, Verdana, Arial, Helvetica, Geneva, Georgia, Courier, and… dare I invoke ye, thou my terrible overlord? Times New Roman.

    + +

    Wherefore art thou, my glorious Archer? And thee as well, my beautiful Garamond? The technical restrictions of that horrible monster we know as the Web Browser hath forced us all too long to use those most banal, those most common, and those most abused, out of all of the typefaces of the world.

    + +

    All hyperbole aside, I’m extremely happy to see the advent of a standard @font-face declaration in CSS. Internet Explorer first implemented a crutched, basic version of this way back in version 4, but nothing ever really came of it - their decision to create the proprietary .EOT2 format to appease overly restrictive type foundries’ worries about intellectual property (aka. the cold, hard dominatrix that we know only as Ms. Profit) truly and completely killed that initial attempt at bringing astute typography and it’s advocates to the web. This new run at @font-face by an established, trusted, and open group (the W3C itself, responsible for helping to make much of what we use as designers on the web standard and cross-system compatible) has a much better chance, in my humble opinion - and I am quite looking forward to the consequences if it succeeds.

    + +

    Now, onwards to the topic of my post as declared in the header (yes, I know, a slow start - but it’s an interesting topic with an interesting history!). WebKit, the open source rendering engine behind the wonderfulness that is Safari, and how it handles the ‘new’ @font-face declaration. No, it’s not really ‘new’, but yes, it feels like it is.

    + +

    To put it simply, and to be very blunt, it’s broken.

    + +

    The CSS spec section for @font-face is very specific - typefaces are to be selected based on a wide array of criteria placed in the @font-face declaration block itself. Various textual CSS attributes may be defined within the @font-face declaration, and then they will be checked when the typeface is referred to later in the CSS. For instance, if I have two @font-face declarations for the Diavlo family - one for regular text, and one for a heavier weighted version of the typeface - then I later utilize Diavlo in a font-family: attribute, it should refer to the basic Diavlo font defined in the first @font-face. However, if I were to do the same, but also specify a heavy font-weight:, then it should use the heavier version of Diavlo. To place this example in code:

    + +
    @font-face {
+  font-family: 'Diavlo';
+  src: url(./Diavlo/Diavlo_Book.otf) format("opentype");
+}
+
+@font-face {
+  font-family: 'Diavlo';
+  font-weight: 900;
+  src: url(./Diavlo/Diavlo_Black.otf) format("opentype");
+}
+
+h1, h2, h3, h4, h5, h6 {
+  font-family: 'Diavlo';
+  font-weight: 900;
+}
+
+div#content {
+  font-family: 'Diavlo';
+}
    + +

    As you can see, my headings should use the typeface defined in Diavlo_Black.otf, while my body content should use Diavlo_Book.otf. However, in WebKit, this doesn’t work - it completely ignores any attribute except font-family: and src: in a @font-face declaration! Completely ignores them! Not only that - not only that - it disregards all but the last @font-face for a given font-family: attribute string!

    + +

    The implication here is that, to make @font-face work as it is currently implemented in WebKit (and thus, Safari 3.1), I have to declare completely imaginary, non-existent type families to satisfy WebKit alone. Here’s the method I have used in the places I current implement @font-face:

    + +
    @font-face {
+  font-family: 'Diavlo Book';
+  src: url(./Diavlo/Diavlo_Book.otf) format("opentype");
+}
+
+@font-face {
+  font-family: 'Diavlo Black';
+  src: url(./Diavlo/Diavlo_Black.otf) format("opentype");
+}
+
+h1, h2, h3, h4, h5, h6 {
+  font-family: 'Diavlo Black';
+}
+
+div#content {
+  font-family: 'Diavlo Book';
+}
    + +

    Isn’t it horrible? Seriously, my eyes, they bleed. There’s lots of problems with this far beyond the lack of semanticity when it comes to the typeface names… let me see how many ways this breaks the purpose of @font-face:

    + +
      +
    • +

      You remove a large element our control over the display of the page.

      + +

      As soon as we begin to use @font-face in our page, we can no longer make any use of any other textual control attribute - font-weight:, font-style:, and font-variant: are no longer available to us, because they no longer correctly map to technical typeface variant/features.

      + +

      Also, many default elements are destroyed, unusable, without ‘fixing’ - for instance, <b> would have no effect in a page styled for WebKit as above; We would have to specify something like b {font-family: 'Diavlo Black';} - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes?

      + +

      If we want to use Javascript to modify the display of the content, we can’t simply adjust the mentioned textual control attributes - we have to know and change the entire font-family: array of strings.

      +
      • + +
    • +

      You make us very wet.

      + +

      And by wet, I mean ‘not DRY’. What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typeface’s bastardized name.

      +
      • + +
    • +

      You remove our user’s user choice, and waste bandwidth.

      + +

      Since the names refer to families that don’t, in fact, exist, the browser can’t override the declaration with a user’s installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser won’t use that - it doesn’t know to use ‘Diavlo’, which the user has installed, because it was told to use ‘Diavlo Black’, which no user in the entire world has installed on their computer.

      +
      • +
    + +

    This whole thing is rather worrying - I’ve heard Opera has @font-face support, though I haven’t had time to test this myself, so I don’t know if it actually does - or, for that matter, if it does it ‘correctly’, or has the same problems as WebKit. But either way, WebKit is one of the first two implementations to ever attempt to support @font-face (Microsoft’s unrelated @font-face declaration notwithstanding) - I really don’t want to see it’s early mistakes carried on to FireFox in a few years, and then Internet Explorer a few decades after that. That will leave us stuck with this broken system forever, as it has been demonstrated time and time again that if nobody else supports an old standard correctly, a newcomer to the standard will not do it correctly either. I for one would really, really, hate that.

    + +

    In summary… come on, WebKit team, this isn’t like you - you’re always the ones with the closest-to-standard implementation, and the cleanest code, and… hell, overall? Webkit is the most secure/fastest browser available. But this is making me lose my faith in you, guys, please get it right. You’re pioneering a leap into the future when it comes to the Web - this is as important, or more important, than Mosiac’s allowing of images was.

    + +

    To put it succinctly - don’t fuck this up, y’all.

    +
    1. +

      These are fonts by Jos Buivenga, quite the amazing person. His (free) fonts are, uniquely, released for use on the web in @font-face declarations - unlike the vast majority of other (even free to download) typefaces, which have ridiculously restricting licenses and terms of use statements. Props, Jos - you’re a pioneer, and deserve recognition as such.

      +↩
    2. +

      To give Microsoft a little credit, something I rarely do… Yes, I’m aware Microsoft submitted EOT to the W3C as a proposal - the problem isn’t with their attempts to make it non-proprietary, but with the basic concept of making typefaces on the web DRMed. Look what such attempts have done to the music and video industry - simply decimated it. Do we really want to see the same thing happen to our beloved medium as typography moves into the 21st century?

      +↩
    +*** Output of to_latex *** +-----| WARNING | ----- +\hypertarget{webkit_safari_31_and_the_css_fontface_declaration}{}\section*{{WebKit (Safari 3.1) and the CSS @font-face declaration}}\label{webkit_safari_31_and_the_css_fontface_declaration} + +I'{}m a big fan of typography in general. If you check out \href{http://elliottcable.name}{my homepage} or my \href{http://elliottcable.name/contact.xhtml}{contact elliottcable} page, and you'{}re using Safari/WebKit or Opera/Kestrel, you'{}ll notice the typefaces (fonts, as colloquialized) are \emph{very} non-standard. (As of this writing, I'{}m using \href{http://www.josbuivenga.demon.nl/museo.html}{Museo} and \href{http://www.josbuivenga.demon.nl/diavlo.html}{Diavlo}\footnote{These are fonts by \href{jos}{Jos Buivenga}, quite the amazing person. His (free) fonts are, uniquely, released for use on the web in {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} declarations - unlike the vast majority of other (even free to download) typefaces, which have ridiculously restricting licenses and terms of use statements. Props, Jos - you'{}re a pioneer, and deserve recognition as such.} heavily on both.) + +The internet has not be a friendly place for typohiles like myself, up to this point, at least. One might even say it was a frightful, mentally scarring environment for those akin to yours truly. We'{}ve been restricted to reading page after page after page on day after day after day for year after year after year abominations of markup and design enslaved by the horrible overlords we know as Lucida, Verdana, Arial, Helvetica, Geneva, Georgia, Courier, and\ldots{} dare I invoke ye, thou my terrible overlord? Times New Roman. + +Wherefore art thou, my glorious Archer? And thee as well, my beautiful Garamond? The technical restrictions of that horrible monster we know as the Web Browser hath forced us all too long to use those most banal, those most common, and those most abused, out of all of the typefaces of the world. + +All hyperbole aside, I'{}m extremely happy to see the advent of a standard {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} declaration in CSS. Internet Explorer first implemented a crutched, basic version of this way back in version 4, but nothing ever really came of it - their decision to create the proprietary .EOT\footnote{To give Microsoft a little credit, something I rarely do\ldots{} Yes, I'{}m aware Microsoft submitted EOT to the W3C as a proposal - the problem isn'{}t with their attempts to make it non-proprietary, but with the basic concept of making typefaces on the web DRMed. Look what such attempts have done to the music and video industry - simply decimated it. Do we really want to see the same thing happen to our beloved medium as typography moves into the 21st century?} format to appease overly restrictive type foundries'{} worries about intellectual property (aka. the cold, hard dominatrix that we know only as Ms. Profit) truly and completely killed that initial attempt at bringing astute typography and it'{}s advocates to the web. This new run at {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} by an established, trusted, and open group (the \href{http://w3c.org}{W3C} itself, responsible for helping to make much of what we use as designers on the web standard and cross-system compatible) has a much better chance, in my humble opinion - and I am quite looking forward to the consequences if it succeeds. + +Now, onwards to the topic of my post as declared in the header (yes, I know, a slow start - but it'{}s an interesting topic with an interesting history!). WebKit, the open source rendering engine behind the wonderfulness that is Safari, and how it handles the `{}new'{} {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} declaration. No, it'{}s not really `{}new'{}, but yes, it feels like it is. + +To put it simply, and to be very blunt, it'{}s broken. + +The \href{http://?}{CSS spec section} for {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} is very specific - typefaces are to be selected based on a wide array of criteria placed in the {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} declaration block itself. Various textual CSS attributes may be defined within the {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} declaration, and then they will be checked when the typeface is referred to later in the CSS. For instance, if I have two {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} declarations for the Diavlo family - one for regular text, and one for a heavier weighted version of the typeface - then I later utilize Diavlo in a {\colorbox[rgb]{1.00,0.93,1.00}{\tt font\char45family\char58}} attribute, it should refer to the basic Diavlo font defined in the first {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}}. However, if I were to do the same, but also specify a heavy {\colorbox[rgb]{1.00,0.93,1.00}{\tt font\char45weight\char58}}, then it should use the heavier version of Diavlo. To place this example in code: + +\begin{verbatim}@font-face { + font-family: 'Diavlo'; + src: url(./Diavlo/Diavlo_Book.otf) format("opentype"); +} + +@font-face { + font-family: 'Diavlo'; + font-weight: 900; + src: url(./Diavlo/Diavlo_Black.otf) format("opentype"); +} + +h1, h2, h3, h4, h5, h6 { + font-family: 'Diavlo'; + font-weight: 900; +} + +div#content { + font-family: 'Diavlo'; +}\end{verbatim} +As you can see, my headings should use the typeface defined in {\colorbox[rgb]{1.00,0.93,1.00}{\tt Diavlo\char95Black\char46otf}}, while my body content should use {\colorbox[rgb]{1.00,0.93,1.00}{\tt Diavlo\char95Book\char46otf}}. However, in WebKit, this doesn'{}t work - it completely ignores any attribute except {\colorbox[rgb]{1.00,0.93,1.00}{\tt font\char45family\char58}} and {\colorbox[rgb]{1.00,0.93,1.00}{\tt src\char58}} in a {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} declaration! Completely ignores them! Not only that - not \emph{only} that - it disregards all but the last {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} for a given {\colorbox[rgb]{1.00,0.93,1.00}{\tt font\char45family\char58}} attribute string! + +The implication here is that, to make {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} work as it is currently implemented in WebKit (and thus, Safari 3.1), I have to declare \emph{completely imaginary, non-existent type families} to satisfy WebKit alone. Here'{}s the method I have used in the places I current implement {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}}: + +\begin{verbatim}@font-face { + font-family: 'Diavlo Book'; + src: url(./Diavlo/Diavlo_Book.otf) format("opentype"); +} + +@font-face { + font-family: 'Diavlo Black'; + src: url(./Diavlo/Diavlo_Black.otf) format("opentype"); +} + +h1, h2, h3, h4, h5, h6 { + font-family: 'Diavlo Black'; +} + +div#content { + font-family: 'Diavlo Book'; +}\end{verbatim} +Isn'{}t it horrible? Seriously, my eyes, they bleed. There'{}s lots of problems with this far beyond the lack of semanticity when it comes to the typeface names\ldots{} let me see how many ways this breaks the purpose of {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}}: + +\begin{itemize}% +\item You remove a large element our control over the display of the page. + +As soon as we begin to use {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} in our page, we can no longer make any use of any other textual control attribute - {\colorbox[rgb]{1.00,0.93,1.00}{\tt font\char45weight\char58}}, {\colorbox[rgb]{1.00,0.93,1.00}{\tt font\char45style\char58}}, and {\colorbox[rgb]{1.00,0.93,1.00}{\tt font\char45variant\char58}} are no longer available to us, because they no longer correctly map to technical typeface variant/features. + +Also, many default elements are destroyed, unusable, without `{}fixing'{} - for instance, {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char60b\char62}} would have no effect in a page styled for WebKit as above; We would have to specify something like {\colorbox[rgb]{1.00,0.93,1.00}{\tt b~\char123font\char45family\char58~\char39Diavlo~Black\char39\char59\char125}} - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes? + +If we want to use Javascript to modify the display of the content, we can'{}t simply adjust the mentioned textual control attributes - we have to know and change the entire {\colorbox[rgb]{1.00,0.93,1.00}{\tt font\char45family\char58}} array of strings. + + +\item You make us very wet. + +And by wet, I mean `{}not DRY'{}. What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typeface'{}s bastardized name. + + +\item You remove our user'{}s user choice, and waste bandwidth. + +Since the names refer to families that don'{}t, in fact, exist, the browser can'{}t override the declaration with a user'{}s installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser won'{}t use that - it doesn'{}t know to use `{}Diavlo'{}, which the user has installed, because it was told to use `{}Diavlo Black'{}, which no user in the entire world has installed on their computer. + + + +\end{itemize} +This whole thing is rather worrying - I'{}ve heard Opera has {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} support, though I haven'{}t had time to test this myself, so I don'{}t know if it actually does - or, for that matter, if it does it `{}correctly'{}, or has the same problems as WebKit. But either way, WebKit is one of the first two implementations to ever attempt to support {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} (Microsoft'{}s unrelated {\colorbox[rgb]{1.00,0.93,1.00}{\tt \char64font\char45face}} declaration notwithstanding) - I really don'{}t want to see it'{}s early mistakes carried on to FireFox in a few years, and then Internet Explorer a few decades after that. That will leave us stuck with this broken system forever, as it has been demonstrated time and time again that if nobody else supports an old standard correctly, a newcomer to the standard will not do it correctly either. I for one would really, really, hate that. + +In summary\ldots{} come on, WebKit team, this isn'{}t like you - you'{}re always the ones with the closest-to-standard implementation, and the cleanest code, and\ldots{} hell, overall? Webkit is the most secure/fastest browser available. But this is making me lose my faith in you, guys, please get it right. You'{}re pioneering a leap into the future when it comes to the Web - this is as important, or \emph{more} important, than Mosiac'{}s allowing of images was. + +To put it succinctly - don'{}t fuck this up, y'{}all. +*** Output of to_md *** +-----| WARNING | ----- +WebKit (Safari 3.1) and the CSS @font-face declarationI m a big fan of typography in general. +If you check out my homepageor my +contact elliottcablepage, and you re +using Safari/WebKit or Opera/Kestrel, +you ll notice the typefaces (fonts, as +colloquialized) are verynon-standard. +(As of this writing, I m using Museoand +Diavloheavily on both.) + +The internet has not be a friendly +place for typohiles like myself, up to +this point, at least. One might even +say it was a frightful, mentally +scarring environment for those akin to +yours truly. We ve been restricted to +reading page after page after page on +day after day after day for year after +year after year abominations of markup +and design enslaved by the horrible +overlords we know as Lucida, Verdana, +Arial, Helvetica, Geneva, Georgia, +Courier, and dare I invoke ye, thou my +terrible overlord? Times New Roman. + +Wherefore art thou, my glorious Archer? +And thee as well, my beautiful +Garamond? The technical restrictions of +that horrible monster we know as the +Web Browser hath forced us all too long +to use those most banal, those most +common, and those most abused, out of +all of the typefaces of the world. + +All hyperbole aside, I m extremely +happy to see the advent of a standard +declaration in CSS. Internet Explorer +first implemented a crutched, basic +version of this way back in version 4, +but nothing ever really came of it - +their decision to create the +proprietary .EOTformat to appease +overly restrictive type foundries +worries about intellectual property +(aka. the cold, hard dominatrix that we +know only as Ms. Profit) truly and +completely killed that initial attempt +at bringing astute typography and it s +advocates to the web. This new run at +by an established, trusted, and open +group (the W3Citself, responsible for +helping to make much of what we use as +designers on the web standard and +cross-system compatible) has a much +better chance, in my humble opinion - +and I am quite looking forward to the +consequences if it succeeds. + +Now, onwards to the topic of my post as +declared in the header (yes, I know, a +slow start - but it s an interesting +topic with an interesting history!). +WebKit, the open source rendering +engine behind the wonderfulness that is +Safari, and how it handles the new +declaration. No, it s not really new , +but yes, it feels like it is. + +To put it simply, and to be very blunt, +it s broken. + +The CSS spec sectionfor is very +specific - typefaces are to be selected +based on a wide array of criteria +placed in the declaration block itself. +Various textual CSSattributes may be +defined within the declaration, and +then they will be checked when the +typeface is referred to later in the CSS +. For instance, if I have two +declarations for the Diavlo family - +one for regular text, and one for a +heavier weighted version of the +typeface - then I later utilize Diavlo +in a attribute, it should refer to the +basic Diavlo font defined in the first +. However, if I were to do the same, +but also specify a heavy , then it +should use the heavier version of +Diavlo. To place this example in code: + +As you can see, my headings should use +the typeface defined in , while my body +content should use . However, in +WebKit, this doesn t work - it +completely ignores any attribute except +and in a declaration! Completely +ignores them! Not only that - not only +that - it disregards all but the last +for a given attribute string! + +The implication here is that, to make +work as it is currently implemented in +WebKit (and thus, Safari 3.1), I have +to declare +completely imaginary, non-existent type families +to satisfy WebKit alone. Here s the +method I have used in the places I +current implement : + +Isn t it horrible? Seriously, my eyes, +they bleed. There s lots of problems +with this far beyond the lack of +semanticity when it comes to the +typeface names let me see how many ways +this breaks the purpose of : + +-You remove a large element our control over the display of the page. +As soon as we begin to use in our page, we can no longer make any use of any other textual control attribute - , , and are no longer available to us, because they no longer correctly map to technical typeface variant/features. +Also, many default elements are destroyed, unusable, without fixing - for instance, would have no effect in a page styled for WebKit as above; We would have to specify something like - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes? +If we want to use Javascript to modify the display of the content, we cant simply adjust the mentioned textual control attributes - we have to know and change the entire array of strings. +-ou make us very wet. +And by wet, I mean not DRY. What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typefaces bastardized name. +-You remove our users user choice, and waste bandwidth. +Since the names refer to families that dont, in fact, exist, the browser cant override the declaration with a users installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser wont use that - it doesnt know to use Diavlo, which the user has installed, because it was told to use Diavlo Black, which no user in the entire world has installed on their computer. + +This whole thing is rather worrying - I +ve heard Opera has support, though I +haven t had time to test this myself, +so I don t know if it actually does - +or, for that matter, if it does it +correctly , or has the same problems as +WebKit. But either way, WebKit is one +of the first two implementations to +ever attempt to support (Microsoft s +unrelated declaration notwithstanding) +- I really don t want to see it s early +mistakes carried on to FireFox in a few +years, and then Internet Explorer a few +decades after that. That will leave us +stuck with this broken system forever, +as it has been demonstrated time and +time again that if nobody else supports +an old standard correctly, a newcomer +to the standard will not do it +correctly either. I for one would +really, really, hate that. + +In summary come on, WebKit team, this +isn t like you - you re always the ones +with the closest-to-standard +implementation, and the cleanest code, +and hell, overall? Webkit is the most +secure/fastest browser available. But +this is making me lose my faith in you, +guys, please get it right. You re +pioneering a leap into the future when +it comes to the Web - this is as +important, or moreimportant, than +Mosiac s allowing of images was. + +To put it succinctly - don t fuck this +up, y all. + +These are fonts by Jos Buivenga, quite +the amazing person. His (free) fonts +are, uniquely, released for use on the +web in declarations - unlike the vast +majority of other (even free to +download) typefaces, which have +ridiculously restricting licenses and +terms of use statements. Props, Jos - +you re a pioneer, and deserve +recognition as such. + +*[CSS]: Cascading Style Sheets +*[.EOT]: Embedded OpenType +To give Microsoft a little credit, +something I rarely do Yes, I m aware +Microsoft submitted EOT to the W3Cas a +proposal - the problem isn t with their +attempts to make it non-proprietary, +but with the basic concept of making +typefaces on the web DRMed. Look what +such attempts have done to the music +and video industry - simply decimated +it. Do we really want to see the same +thing happen to our beloved medium as +typography moves into the 21st century? + +*[W3C]: World Wide Web Consortium +*[DRY]: Don't Repeat Yourself +*** Output of to_s *** +-----| WARNING | ----- +WebKit (Safari 3.1) and the CSS @font-face declarationIm a big fan of typography in general. If you check out my homepage or my contact elliottcable page, and youre using Safari/WebKit or Opera/Kestrel, youll notice the typefaces (fonts, as colloquialized) are very non-standard. (As of this writing, Im using Museo and Diavlo heavily on both.)The internet has not be a friendly place for typohiles like myself, up to this point, at least. One might even say it was a frightful, mentally scarring environment for those akin to yours truly. Weve been restricted to reading page after page after page on day after day after day for year after year after year abominations of markup and design enslaved by the horrible overlords we know as Lucida, Verdana, Arial, Helvetica, Geneva, Georgia, Courier, and dare I invoke ye, thou my terrible overlord? Times New Roman.Wherefore art thou, my glorious Archer? And thee as well, my beautiful Garamond? The technical restrictions of that horrible monster we know as the Web Browser hath forced us all too long to use those most banal, those most common, and those most abused, out of all of the typefaces of the world.All hyperbole aside, Im extremely happy to see the advent of a standard declaration in CSS. Internet Explorer first implemented a crutched, basic version of this way back in version 4, but nothing ever really came of it - their decision to create the proprietary .EOT format to appease overly restrictive type foundries worries about intellectual property (aka. the cold, hard dominatrix that we know only as Ms. Profit) truly and completely killed that initial attempt at bringing astute typography and its advocates to the web. This new run at by an established, trusted, and open group (the W3C itself, responsible for helping to make much of what we use as designers on the web standard and cross-system compatible) has a much better chance, in my humble opinion - and I am quite looking forward to the consequences if it succeeds.Now, onwards to the topic of my post as declared in the header (yes, I know, a slow start - but its an interesting topic with an interesting history!). WebKit, the open source rendering engine behind the wonderfulness that is Safari, and how it handles the new declaration. No, its not really new, but yes, it feels like it is.To put it simply, and to be very blunt, its broken.The CSS spec section for is very specific - typefaces are to be selected based on a wide array of criteria placed in the declaration block itself. Various textual CSS attributes may be defined within the declaration, and then they will be checked when the typeface is referred to later in the CSS. For instance, if I have two declarations for the Diavlo family - one for regular text, and one for a heavier weighted version of the typeface - then I later utilize Diavlo in a attribute, it should refer to the basic Diavlo font defined in the first . However, if I were to do the same, but also specify a heavy , then it should use the heavier version of Diavlo. To place this example in code:As you can see, my headings should use the typeface defined in , while my body content should use . However, in WebKit, this doesnt work - it completely ignores any attribute except and in a declaration! Completely ignores them! Not only that - not only that - it disregards all but the last for a given attribute string!The implication here is that, to make work as it is currently implemented in WebKit (and thus, Safari 3.1), I have to declare completely imaginary, non-existent type families to satisfy WebKit alone. Heres the method I have used in the places I current implement :Isnt it horrible? Seriously, my eyes, they bleed. Theres lots of problems with this far beyond the lack of semanticity when it comes to the typeface names let me see how many ways this breaks the purpose of :You remove a large element our control over the display of the page.As soon as we begin to use in our page, we can no longer make any use of any other textual control attribute - , , and are no longer available to us, because they no longer correctly map to technical typeface variant/features.Also, many default elements are destroyed, unusable, without fixing - for instance, would have no effect in a page styled for WebKit as above; We would have to specify something like - how broken is that? Unless we caught all such default elements and re-styled them to use the bastardized names instead of the correct attributes, lots of basic HTML formatting would be broken. I myself may never use in-document formatting (separation of design and content!), but what about comments forms? Forum posts? Direct HTML-literal quotes?If we want to use Javascript to modify the display of the content, we cant simply adjust the mentioned textual control attributes - we have to know and change the entire array of strings.You make us very wet.And by wet, I mean not DRY. What if we decide to change one of the bastardized font names? Or use a different font entirely? We have to go through all of our CSS, all of our Javascript, and make sure we update every occurrence of the typefaces bastardized name.You remove our users user choice, and waste bandwidth.Since the names refer to families that dont, in fact, exist, the browser cant override the declaration with a users installed version of the typeface. This means that, regardless of whether the user already has the typeface installed on their own computer, the browser wont use that - it doesnt know to use Diavlo, which the user has installed, because it was told to use Diavlo Black, which no user in the entire world has installed on their computer.This whole thing is rather worrying - Ive heard Opera has support, though I havent had time to test this myself, so I dont know if it actually does - or, for that matter, if it does it correctly, or has the same problems as WebKit. But either way, WebKit is one of the first two implementations to ever attempt to support (Microsofts unrelated declaration notwithstanding) - I really dont want to see its early mistakes carried on to FireFox in a few years, and then Internet Explorer a few decades after that. That will leave us stuck with this broken system forever, as it has been demonstrated time and time again that if nobody else supports an old standard correctly, a newcomer to the standard will not do it correctly either. I for one would really, really, hate that.In summary come on, WebKit team, this isnt like you - youre always the ones with the closest-to-standard implementation, and the cleanest code, and hell, overall? Webkit is the most secure/fastest browser available. But this is making me lose my faith in you, guys, please get it right. Youre pioneering a leap into the future when it comes to the Web - this is as important, or more important, than Mosiacs allowing of images was.To put it succinctly - dont fuck this up, yall.These are fonts by Jos Buivenga, quite the amazing person. His (free) fonts are, uniquely, released for use on the web in declarations - unlike the vast majority of other (even free to download) typefaces, which have ridiculously restricting licenses and terms of use statements. Props, Jos - youre a pioneer, and deserve recognition as such.To give Microsoft a little credit, something I rarely do Yes, Im aware Microsoft submitted EOT to the W3C as a proposal - the problem isnt with their attempts to make it non-proprietary, but with the basic concept of making typefaces on the web DRMed. Look what such attempts have done to the music and video industry - simply decimated it. Do we really want to see the same thing happen to our beloved medium as typography moves into the 21st century? +*** Output of Markdown.pl *** +(not used anymore) +*** Output of Markdown.pl (parsed) *** +(not used anymore) \ No newline at end of file diff --git a/vendor/plugins/maruku/tests/unittest/red_tests/xml.html b/vendor/plugins/maruku/tests/unittest/red_tests/xml.html new file mode 100644 index 00000000..df1f6871 --- /dev/null +++ b/vendor/plugins/maruku/tests/unittest/red_tests/xml.html @@ -0,0 +1,15 @@ + + + + +
    REXML could not parse this XML/HTML: 
+<svg:svg/>
    REXML could not parse this XML/HTML: 
+<svg:svg 
+width="600px" height="400px">
+  <svg:g id="group">
+	<svg:circle id="circ1" r="1cm" cx="3cm" cy="3cm" style="fill:red;"></svg:circle>
+	<svg:circle id="circ2" r="1cm" cx="7cm" cy="3cm" style="fill:red;" />
+  </svg:g>
+</svg:svg>
    \ No newline at end of file diff --git a/vendor/plugins/maruku/tests/unittest/red_tests/xml.md b/vendor/plugins/maruku/tests/unittest/red_tests/xml.md new file mode 100644 index 00000000..0c304ea2 --- /dev/null +++ b/vendor/plugins/maruku/tests/unittest/red_tests/xml.md @@ -0,0 +1,70 @@ +Write a comment here +*** Parameters: *** +{:on_error=>:raise} +*** Markdown input: *** + + + + + + + + + + + + +*** Output of inspect *** +md_el(:document,[ + md_html(""), + md_html("\n \n\t\n\t\n \n") +],{},[]) +*** Output of to_html *** + + + + + + +*** Output of to_latex *** + +*** Output of to_md *** + +*** Output of to_s *** + +*** EOF *** + + + + +Failed tests: [:inspect, :to_html] + +*** Output of inspect *** +-----| WARNING | ----- +md_el(:document,[ + md_html(""), + md_html(""), + md_html("\n \n\t\n\t\n \n") +],{},[]) +*** Output of to_html *** +-----| WARNING | ----- +
    REXML could not parse this XML/HTML: 
+<svg:svg/>
    REXML could not parse this XML/HTML: 
+<svg:svg 
+width="600px" height="400px">
+  <svg:g id="group">
+	<svg:circle id="circ1" r="1cm" cx="3cm" cy="3cm" style="fill:red;"></svg:circle>
+	<svg:circle id="circ2" r="1cm" cx="7cm" cy="3cm" style="fill:red;" />
+  </svg:g>
+</svg:svg>
    +*** Output of to_latex *** + +*** Output of to_md *** + +*** Output of to_s *** + +*** Output of Markdown.pl *** +(not used anymore) +*** Output of Markdown.pl (parsed) *** +(not used anymore) \ No newline at end of file